2009年8月4日
#
摘要: 之前遇到幾次現場故障，都是和class文件有關，比如版本不兼容造成Bad Version錯誤之類，需要檢查class文件的編譯版本信息。 今天無意中發現， jdk自帶的javap 命令其實可以方便的搞定這個事情
閱讀全文
摘要: 前幾次的編碼最佳實踐系列，我們都著眼于Java代碼，今天我們換個話題，看看另外一個領域，和Java代碼大相徑庭的SQL。
閱讀全文
摘要: 本期的案例依然是來自實際項目，很尋常的代碼，卻意外遭遇傳說中的Java"內存溢出"。
閱讀全文
摘要: 昨晚繼續折騰俺的小站http://www.javauniversity.net，準備給它加上SEO支持，安裝了SEO tools模塊和相應的依賴模塊。
結果安裝完成之后就陷入重定向循環了，每個頁面都被重定向到新地址，然后新地址再次被重定向。chrome瀏覽器會稍后報錯說太多重定向，而ie則傻傻的一直在死循環。
閱讀全文
摘要: 折騰了兩天，終于將Java University這個站點開通，過程真不容易的，決定寫下來吐吐 糟，以紀念TIANCHAO和諧之光普照下P民的美好生活
閱讀全文
摘要: 這是一個來自實際項目的例子，在這個案例中，有同事基于jdk中的LinkedHashMap設計了一個LRUCache，為了提高性能，使用了 ReentrantReadWriteLock 讀寫鎖：寫鎖對應put()方法，而讀鎖對應get()方法，期望通過讀寫鎖來實現并發get()。
閱讀全文
摘要: 這里將要講述的是一系列的類似案例，都是在各個產品進行performance tuning時被發現的，非常具有普適性。可以說在日常開發中，有非常大的概率遇到相同或者類似的情形，因此需要對其保持警惕以便避免陷入類似的性能問題。 我們從JAXBContext這個對象開始...
閱讀全文
摘要: 這是一個真實案例，曾經惹出碩大風波，故事的起因卻很簡單，就是需要實現一個簡單的計數器，每次取值然后加1......
閱讀全文
摘要: 最近在公司內部做了一些收集和整理的工作，關于trouble shooting和performace tuning 中遇到并解決的典型問題，做了一些內部分享。我整理了一下，準備陸續放上來分享給大家。
這些問題，單個看每個問題都不算復雜或高深，但是都是在實際項目開發中出現并一度造成困擾的，而且帶有一定的普適性，具體表現為不知道這些問題的同學很容易在日常開發中中招。因此我們開了一個專題，叫做編碼最佳實踐，似乎名字起的有點大......
先來看看第一個，如何做compare。
閱讀全文
摘要: 今天用jetty做嵌入式web container，來做web項目的integration test，結果發現出現在渲染使用EL表達式的jsp頁面時出現異常：
javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory;
檢查了一下，發現javax.el.ExpressionFactory.newInstance()這個方法是EL2.2版本之后才有的方法，而在EL2.1之中是沒有這個方法的，問題很明顯：org.apache.jasper中試圖調用2.2版本的EL，當時提供的EL的版本是2.1版本，所以解決的方式無非就是兩個，要不降低org.apache.jasper的版本，要不提升el的版本。考慮到現在使用的jetty已經是最新的版本8.1.2.v20120308，因此提升EL的版本為2.2更為合適。
閱讀全文
摘要: 在jenkins上建立了一個job，通過標準的maven命令來執行打包測試和上傳artifact到nexus倉庫。隨后發現有些性能問題：sonar的job執行時，需要重新update SCM，然后需要再次執行test，之后才能進行真正屬于sonar的任務如代碼檢測等。明顯update SCM 和執行test是重復了原有job，純屬浪費。這個重復執行問題隨著測試案例和測試執行時間的增加，會越來越明顯。因此需要考慮消除這里的重復問題，減少build的時間，并節約jenkins的資源。
閱讀全文
使用maven填寫依賴的時候，常會遇到需要查一下groupId/artifactId和version，有時候還要看看有沒有新的版本更新。
原來一直用http://mvnrepository.com/ 這個網站來搜索，最近發現maven官網也提供了類似的功能，http://search.maven.org/。
簡單試用了一下search.maven.org，功能基本和mvnrepository.com相同，而且界面更簡潔友好。推薦使用。
摘要: cloudfoundry是vmvare新推出來的開源PaaS平臺，我試用了一下，發現還是很不錯的，申請過程很簡單。發出來分享給大家，有需要的可以去申請，畢竟可以支持java的免費的空間實在太難得了。
閱讀全文
摘要: 初學gradle，一切都還在摸索的過程中。今天剛剛試圖將之前基于ant + ivy的一個小項目轉移到gradle下，結果在和sonar集成時出現問題.
閱讀全文
摘要: 雖然easymock中提供了大量的方法來進行參數匹配，但是對于一些特殊場合比如參數是復雜對象而又不能簡單的通過equals()方法來比較，這些現有的參數匹配器就無能為力了。easymock為此提供了IArgumentMatcher 接口來讓我們實現自定義的參數匹配器。
閱讀全文
摘要: 在easymock中，對于mock對象的同一個方法，可以為每一次的調用定制不同的行為。在record階段easymock會精確的記錄我們錄入的行為，基于每一次的方法調用。
閱讀全文
摘要: 前面的教程中，我們看到easymock可以通過expect方法來設定mock方法的返回值或者異常，但是注意這些案例中設置的返回值都是在調用被測試的類的方法前就已經確定下來的，即我們其實在測試類的代碼運行前(實際是在EasyMock.replay()方法調用前)就已經"預知"了返回結果。
但是在某些情況下，我們可能無法預知返回值，比如我們需要根據輸入的參數值來決定返回什么，而這個參數可能無法在record階段獲得。因此在mock方法中我們無法在record階段就決定應該返回什么。
對于這種場景，easymock提供了IAnswer接口和andAnswer()方法來提供運行時決定返回值或者異常的機制。
閱讀全文
摘要: easymock中提供對于類的mock功能，我們可以方便的mock這個類的某些方法，指定預期的行為以便測試這個類的調用者。這種場景下被mock的類在測試案例中扮演的是次要測試對象或者說依賴的角色，主要測試對象是這個mock類的調用者。但是有時候我們需要將這個測試類作為主要測試對象，我們希望這個類中的部分(通常是大部分)方法保持原有的正常行為，只有個別方法被我們mock掉以便測試。
閱讀全文
摘要: easymock中提供了非常多的方法來實現參數匹配，基本能滿足一般參數匹配的要求。
閱讀全文
摘要: 在創建mock對象的時候，我們可以命名mock對象。
命名mock對象有什么好處呢？其實就是一點，即在當測試案例因為某個mock對象的狀態或行為不符合要求而失敗的時候，在異常信息里面可以輸出這個mock對象的名稱。
閱讀全文
摘要: 對于mock對象上的mock方法的調用,easymock支持指定次數，默認為1.同時easymock提供了其他的方法，用于指定具體調用次數或者放寬調用次數檢驗。
閱讀全文
摘要: easymock并不是萬能的，在使用easymock時有一些限制需要注意。
閱讀全文
摘要:
前面教程中有個章節討論到mock和stub的概念差別，一般來說easymock如其名所示，主要是用來做mock用的，但是easymock中也提供有對stub的支持, 主要體現在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
閱讀全文
大家都知道sonar是個好東東，在有CI支持的情況下，使用好了可以非常好的控制代碼的質量，諸如代碼覆蓋率，代碼規則檢查等。
而解決violation的辦法，除了正統的修改代碼來滿足規則外，還有一個變通的方法， NOSONAR。這個標記本意是在一些特殊情況，有不得已的理由不得不違反規則，為了避免sonar繼續報錯而不得已做了一個"變通"。
NOSONAR本意雖好，但要是有人濫用，變通就會變成取巧，因為解決sonar violation的最簡單的方法，就是直接NOSONAR！
當問題很簡單時，一般人都會選擇正常的方式修改代碼，如果只是舉手之勞基本上還是能遵守規則的。但是當問題復雜時，或者說當解決問題不再是舉手之勞時，每個人都要受到NOSONAR的誘惑。而NOSONAR的底線在哪里？沒有人定義，沒有人檢測，自然不會每個人都堅守，NOSONAR的底線隨著一個一個的NOSONAR慢慢的在降低。退五十步的人，是沒有資格笑百步的。
返回到現實代碼中，不知道是大家都沒有頂住誘惑，還是說我們開啟的規則不大合理，總之越來越頻繁的在代碼中看到NOSONAR了，雖然還沒有到泛濫的地步，但是已經讓我有些不安了。簡單搜索了一下剛才讓我感覺到很多NOSONAR的project，結果是58個。
更糟糕的是，每個NOSONAR后面都不會帶有注釋說明為什么要NOSONAR，因此一個個飛舞的NOSONAR就變成了一個個謎團。想知道為什么要NOSONAR嗎？恩，你猜......
我沒有辦法去檢查這個58個NOSONAR是不是都合理的，都站得住腳的。出于程序員的習慣，對于一切不可確認性都報以懷疑的眼光和質疑的姿態，我總覺得這58個NOSONAR讓我總是沒有底，每次我看到sonar上100%的規則檢測通過率時，我總是禁不住在心里浮現NOSONAR的字樣。
好吧，我承認，我是個心里有些陰暗的家伙......
摘要: 在easymock的使用過程中，當創建mock對象時，我們會遇到 strict mock和nice mock的概念。上述的測試案例驗證了strict mock和nice mock的基本使用，對于同一個mock對象，strict模式下多個方法之間的調用順序在record階段和replay階段下是需要保持一致的。但是故事并不是到此結束，更有意思的內容在后面：如果出現多個mock對象，那么這些不同mock對象的方法之間，他們的調用順序是否檢測？普通mock和nice mock模式下自然是不會檢測順序，但是strict模式下呢？
閱讀全文
摘要: IMocksControl接口容許創建多個mock對象，這些創建的對象自動關聯到這個mocksControl實例上，以后再調用replay()/verify()/reset()時就不需要逐個列舉出每個mock對象。當mock對象比較多，尤其是原有代碼上新增mock 對象時非常方便。
閱讀全文
摘要: 前面的例子中，mock的對象都是基于interface，雖然說我們總是強調要面對接口編程，而不要面對實現，但是實際開發中不提取interface而直接使用class的場景非常之多。尤其是一些當前只有一個明確實現而看不到未來擴展的類，是否應該提取interface或者說是否應該現在就提取interface，總是存在爭論。
這種情況下，我們就會面臨主要測試對象依賴到一個具體類而不是interface的情況，easymock中通過class extension 來提供對class mocking的支持。
閱讀全文
摘要: 關于easymock的典型使用方式，在easymock的官網文檔中，有非常詳盡的講解，文檔地址為 http://easymock.org/EasyMock3_0_Documentation.html，文檔的開頭一部分內容都是easymock中最基本的使用介紹，雖然是英文，但是非常容易看懂，適用新學者入門。
這里只羅列一些簡單的常用功能。
閱讀全文
摘要: record-replay-verify 模型容許記錄mock對象上的操作然后重演并驗證這些操作。這是目前mock框架領域最常見的模型，幾乎所有的mock框架都是用這個模型，有些是現實使用如easymock，有些是隱式使用如jmockit。
record-replay-verify 模型非常好的滿足了大多數測試場景的需要：先指定測試的期望，然后執行測試，再驗證期望是否被滿足。這個模型簡單直接，易于實現，也容易被開發人員理解和接受，因此被各個mock框架廣泛使用。
閱讀全文
摘要: 在單元測試中，通常我們都會有一個明確的測試對象，我們測試的主要目的就是為了驗證這個類的工作如我們預期。
閱讀全文
摘要: easymock是目前java mock 工具中比較流行的工具，這個教程將系統的介紹easymock的使用。
主要內容來自easymock的官網教程，針對日常使用進行了一些篩選和補充，另外增加一些個人的理解和認識。
另外考慮到網絡上已有不少分散的教程，我將適當的鏈接進來。
教程的內容將在隨后逐漸添加，目前計劃的目錄如下，相應內容完成之后我將逐個更新此文的鏈接。
閱讀全文
近期發現一個問題，hudson執行任務時，經常不能獲取到最新的代碼，從而導致出現各種問題。
日常開發中的典型例子：發現一個bug，修改代碼，本地測試通過，提交代碼到subversion，手工激活hudson構建，原本期望hudson獲取到剛剛提交的代碼并測試/打包/發布。結果事與愿違，測試的結果發現剛剛做出的修改似乎沒有生效。正費解之時，再執行一次hudson構建，又成功了...
經歷過幾次上述蹊蹺遭遇之后，發現這個問題不是偶然。之后檢查hudson的日志，發現問題的發現在最開始update / check out subversion代碼時，明明已經提交的代碼，hudson做update / check out時，居然沒有update / check out下來！顯示的subversion版本號也和subversion上實際的最新版本不一致，hudson總是要小一些，換言之，hudson update / check out的代碼要比當前最新代碼老一些。
google一番，發現這個問題之前就有人遭遇過，hudson上甚至已經有了好幾個關于這個問題的bug，比如 http://issues.hudson-ci.org/browse/HUDSON-1241 "force using HEAD SVN version for build"。問題的根源在于hudson 獲取subversion代碼的方式，hudson是通過時間戳的方式來獲取代碼，而不是我們一般認為的"最新代碼"即"HEAD"。這種方式通常沒有問題，因為獲取當前時間戳，然后要求update / checkout這個時間戳前的代碼，理論上也是可以拿到最新代碼的。
但是，如果hudson所在的服務器和subversion服務器時間不一致，這個機制就會出現問題:
我們假設subversion服務器的時間是準確的，再假設當時時間是15:10分，開發人員A提交代碼，subversion上當前這個最新提交的代碼時間戳為15:10:00。然后開發人員A手工激活hudson進行構建。hudson在15:10:20時開始check out代碼。如果hudson時間無誤，則hudson會發出請求說要求獲取時間戳在15:10:20之前的代碼，這樣這個實際提交時間為15:10:00的新代碼就可以如期的被check out。但是如果hudson的時鐘有誤，由于某些原因導致時鐘偏慢2分鐘，即在hudson上，"當前時間"為"15:08:20"，則hudson獲取代碼的請求為:獲取時間戳為15:08:20之前的代碼，此時時間戳為15:10:00的新代碼就無法checkout。
幾分鐘之后，疑惑的開發人員A再次激活hudson再次構建，假設此時時間時間是15:15:00，hudson慢兩分鐘為15:13:00。此時hudson發出請求: 獲取時間戳為15:13:00之前的代碼, 因此實際提交時間為15:10:00的新代碼可以正常checkout，問題又在不知不覺被回避了。
總結說，hudson 獲取代碼的機制不是我們直覺中的獲取最新代碼(即subversion中HEAD checkout)，而是基于時間戳。由于這個方式通常如HEAD般工作，因此我們總是容易誤解為是獲取最新代碼。當hudson的時鐘晚于subversion時，悲劇就出現了。
對這個問題，有幾點疑惑：
1. 不明白為什么hudson不采用最直接最簡單最容易被人理解最不容易出誤解的HEAD checkout，而要基于時間戳
2. 這個問題很早就發生了，上面提到的bug 08年就被人提出, "Created: 31/Jan/08 05:37 AM Updated: 01/Jul/10 11:06 AM"，三年了類似的bug被多次提出，但是就是始終沒有修復。
修復的方式很簡單，就改一個類的一行代碼
in Class: hudson.scm.SubversionSCM
line 377:
final SVNRevision revision = SVNRevision.create(timestamp);
replace to:
final SVNRevision revision = SVNRevision.HEAD;
hudson拒絕修復的理由是什么？
Maven 3.0 的第一個RC版本終于發布了，下面是sonatype給出的發布信息：
Maven 在apache上的頁面目前還沒有放出RC1版本。下面是關于mavne3.*版本相對于2.* 版本的改進列表：
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
PS: 坦言說，改進很少，尤其沒有大的功能改進，有點失望。
修訂：上面的URL是兼容性列表，因此看起來和2.*差別不大，是我理解錯了，抱歉。
摘要: 最新版本的confluence 3.3.1 linux 安裝筆記。
閱讀全文
摘要: 之前安裝的fisheye2.2.1，破解不是很好用，最近看到fisheye2.3.6版本有出新的破解方式，特地嘗試了一下，成功安裝。現在將過程簡單分享給大家。
閱讀全文
摘要: 作為測試的基本概念，在開發測試中經常遇到mock和stub。之前認為自己對這兩個概念已經很明白了，但是當決定要寫下來并寫清楚以便能讓不明白的人也能弄明白，似乎就很有困難。
試著寫下此文，以檢驗自己是不是真的明白mock和stub。
閱讀全文
講個笑話吧，關于"keep it simple"
這其實是個真實的故事，發生在兩年前，當我從上一家公司離職時。
當時我移交了一個重要模塊，后來不久，記不清了，大概一兩個月后吧，有關系不錯的同事告訴我說：某某人大肆宣揚，***模塊我只找個了***的人，*天就接手了，云云。
言下之意自不必說。
而我，則將上述評論視為對自己的嘉獎，深以為榮。
*******************************************************************************
為了大家能看懂這個笑話，羅嗦一點介紹兩個背景故事：
1. 最驕傲的事
工作9年了，回首看最令自己驕傲的事情，就是在07年的夏天，加班加點的工作了1個半月，將上述模塊的新需求完成。開發模式是我最喜愛的TDD + 持續重構，完備的unit測試案例覆蓋。后面測試中，3位負責測試同事用了三天的時間，測試完成所有的測試案例，全部一次性通過，沒有一個bug，哪怕是小bug。
此記錄本人之后兩年中一直試圖復制，至今沒有成功。
2. 荒謬的問題
發生在離職做上述模塊移交時，被接收人問了一個問題：項目代碼里面，test目錄下是什么東西啊？
import junit.***, extends TestCase...
無言以對。
摘要: Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節為Tokyo Tyrant的基礎教程。
閱讀全文
摘要:
Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節介紹Tokyo Tyrant的遠程數據庫API，Lua擴展和協議。部分細節內容沒有翻譯。
閱讀全文
摘要:
Tokyo Tyrant基本規范，翻譯自Tokyo Tyrant官網。
本節介紹Tokyo Tyrant的客戶端程序。
閱讀全文
摘要: Tokyo Tyrant基本規范，翻譯自tt官網，地址為http://fallabs.com/tokyotyrant/spex.html。
本節介紹Tokyo Tyrant的服務器程序。
閱讀全文
摘要: Tokyo Tyrant基本規范，翻譯自tt官網，地址為http://fallabs.com/tokyotyrant/spex.html。
本節介紹Tokyo Tyrant的基本知識和安裝方法。
閱讀全文
摘要: Solr是一個基于Lucene java庫的企業級搜索服務器，本文記錄了solr的安裝過程，版本為最新的1.4.1。
閱讀全文
摘要: Tokyo Tyrant是目前評價最高的key-value數據庫之一，本文記錄在linux(suse11)上的安裝過程。
閱讀全文
摘要: 一直在使用easymock作為mock工具，但是easymock有一個一直令我極其惱火的地方：easymock將interface和class的mock區分開，給出了針對interface mock的easyMock和針對class mock的easyMock class extension。兩種mock被嚴格區分開，連jar包都是兩個，使用時不能混用，比如不能用easymock (非class extension)來mock class。
easymock已經發布了新的3.0版本，該版本的主要改進就是消除上述的問題，新版本中可以直接mock class，不再強制使用easyMock class extension。
強烈推薦還在使用2.*的朋友們升級到3.0版本。
閱讀全文
摘要: 有遇到類似的TortoiseSVN / subversive 信息無法識別的問題的朋友，可以這個方法。
閱讀全文
摘要: sonar 安裝配置筆記, 基于SUSE SLSE11, mysql.
閱讀全文
摘要: 近期自己折騰自己，放著正統的maven + junit不用，卻準備用ant + ivy 替代maven做依賴管理，用testng替代junit做單元測試。
閱讀全文
摘要: 眾所周知，對于高動態高可擴展的應用，OSGI是一個非常好的平臺。但是，也因此增加了復雜性，開發中對service的依賴變得復雜。這也是 service的關系管理成為OSGI中一個非常重要的部分，我們來看看OSGI中service依賴關系管理的方式。篇幅原因，只關注發展歷程，不具體介紹每個方式的詳細實現細節。
概括的說，目前在OSGI中主要有以下幾種service依賴關系管理的方法：
1. Service listener
2. Service binder
3. Dependency Manager
4. Declarative Services
5. iPOJO
6. blueprint
閱讀全文
摘要: 當時實際上，我們在檢查ThreadDeath的調用信息時，說明這個出現init()錯誤的filter還是被glassfish正常調用去執行doFilter()方法，這里和j2ee API的要求是不符合的。有點奇怪的是，glassfish一向是以嚴格遵循j2ee規范而著稱，居然在這里一反常態。
而更令人 郁悶的是，glassfish在處理這個有filter初始化出現ServletException異常的webapp時的前后表現：首先這個 webapp的啟動沒有問題，狀態正常。filter也被認為可以正常工作并加入了filter鏈。webapp中的功能正常，可以正常的接收請求并轉發給內容業務處理模塊。從這些跡象看這個webapp基本沒有問題。但是后面glassfish卻莫名其妙的認定，“this web application instance has been stopped already”，從而以ThreadDeath這種非常規的error來報錯。
閱讀全文
摘要: 對比最近遇到的兩個事情，明顯感覺sun有力不從心或者心不在焉的感覺，oracle對sun收購的負面影響至少在開源社區方面是顯而易見的，個人甚至懷疑oracle正在逐漸放棄之前sun一直努力支撐的開源社區。
閱讀全文
摘要: 剛剛鄙視完sun，繼續performance tuning，結果又發現問題。
有點懷疑metro是不是根本就沒有做過性能測試，我們的測試場景，openESB下通過bepl調用4個我們稱為common service的webservice，目前大概做到1200個tps，算下來common service的webservice的tps大概是1200*4 = 5K附近，上面的問題就非常明顯，之前tps沒有上去前沒有這么嚴重。
可以參考我之前的一個blog， http://www.tkk7.com/aoxj/archive/2010/04/29/319706.html，在解決這里提到的http long connection 和 TIME_AIT的問題之前，我們的tps比較低，cpu壓不上去，當時好像這個問題不明顯。后來搞定之后tps上來了才暴露出來。
考慮上一個blog中 == 比較無效導致cache失效的bug，我對metro的代碼質量真是很沒有信息。按說這樣的大型項目，release之前怎么也要做做壓力測試，穩定性測試之
閱讀全文
摘要: 依然是近期工作中發現的問題，真實案例，寫下來分享給大家。
總結：用 == 來比較非enum或者類型安全枚舉的對象實例，這種錯誤一般只有初學者才犯，萬萬沒有想到，能在metro這樣級別的代碼中也能出現。無限感嘆啊，再次援引同事的評語作為本文的結束語：
sun的程序員也是程序員啊！
閱讀全文
摘要: 近日做性能調優，主要是針對web service，運行于glassfish之上
最終的結果，還是比較理想的，修改了兩個參數之后，cpu終于壓上去了，tps也有了巨大的提升，而且TIME_WAIT的連接也大為減少。
但是這兩個max connections參數的名稱，注釋和實際測試中的效果，都有名不副實的感覺，令人極度困惑。
閱讀全文
摘要: fisheye2.2.1 & Crucible 2.2.1 安裝配置筆記。
閱讀全文
摘要: 今天，嘗試使用slf4j + logback的黃金組合，結果發現有點問題，slf4j和logback的最新版本不兼容。當然slf4j是1.6.0-RC0，正式發布時 logback應該會跟進發布新的版本吧。
閱讀全文
摘要: 這是一個真實案例，本周在工作中發現的，案例情況比較極端，因此顯得很滑稽很搞笑。但是深入一下，還是有些東西值得思考：
下一次，如果我面對一個函數/接口，要求傳入一個大對象，我手頭只有一個pk，還有一個現成的函數可以一行代碼就搞定查詢，我要如何才能擋住誘惑？
閱讀全文
摘要:
在SUSE SLES11 下安裝好tomcat6后，考慮方便需要設置tomcat為開機自動運行。
找到tomcat官方的安裝文檔 http://tomcat.apache.org/tomcat-6.0-doc/setup.html，按照要求安裝，中間發現有些問題，記錄下來備忘。
閱讀全文
摘要: 這段時間簡單的試用了一下jira，非常滿意。準備作為個人之后開發的首選缺陷管理工具，但是當時采用的是windows的全集成安裝方式，因此考慮在linux上正式的安裝一下，同時將數據庫換成mysql。
雖然最后的結果不大好，不過上面的這個安裝過程，已經遠比當前google上能找到的資料要多了。如果其他朋友有打算用jira4 + resin4 + mysql的，可以稍微參考，少走彎路。如果最后能安裝成功正確使用，希望能告知正確的安裝方法，謝謝！
閱讀全文
摘要: 前面的blog有提到，在選擇CMS系統時試用java版本的magnolia，結果很失望的放棄了。
重新將目光投向php + mysql的傳統CMS，我選擇了drupal，下面是drupal的安裝配置筆記。
閱讀全文
摘要: SUSE SLES11 上安裝配置mysql的筆記，分享并備忘。
閱讀全文
摘要: 最近想找個cms系統來用用，做點簡單的東西，因為自己比較熟悉java，因此考慮試試java版本的cms系統先，記得之前hibernate網站改版，是換了一個java版本的cms的，特地找過去看了一下，magnolia，google了一下似乎好評還不少。于是下載下來開始研究。
延續這些年的習慣，安裝過程一定要詳細記錄下來，避免日后再次安裝時浪費時間，呵呵。
試用的結果很不好，還沒有正式開始使用就決定放棄，原因請見下文。
閱讀全文
摘要: 安裝SUSE sles11的過程記錄，分享給有類似需要的朋友，同時備忘。
閱讀全文
摘要: 有兩年多沒有使用resin了，最近打算在機器上安裝一個web container跑點java web app，同時也可能需要支持php，原本打算用apache + tomcat,apache可以加載php模塊來提供php支持，tomcat作為java web container。但突然想到resin，似乎是可以直接支持php的，而且resin的速度也是稍微快于tomcat，于是跑到resin的官網看了一下，恩，新出了4.0版本(慚愧，兩年前用的是3.0或者3.1)。
決定用resin試試，老朋友了。但是在安裝過程中，發現了一系列問題，尤其是設置開機自動啟動，記錄下來提供大家參考。
閱讀全文
摘要: 在windows上安裝jira 4.0.2的簡單過程記錄，備忘。
閱讀全文
摘要: 從網上找到的一個設計模式快速參考，感覺做的非常的好，分享給大家。
閱讀全文
摘要: 在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規范的要求，一般不容許直接啟動線程。因此在常見的異步/并行任務執行上，會遭遇到比普通javase程序更多的麻煩。
閱讀全文
摘要: 這是近期工作中遇到的一個問題，cxf在glassfish下timeout設置出現問題，進而引發的關于classloader, JAX-WS的一些小故事，很驚訝的發現cxf在這種情況下根本沒有辦法運行于glassfish平臺。
關鍵字：glassfish, cxf, classloader, JAX-WS, metro。
閱讀全文
摘要: 如題，osgi 資料收集貼，隨時收集，隨時更新。
閱讀全文
摘要: 在討論這個問題前，先簡單的介紹一下雙重解析器的工作原理：顧名思義，雙重解析是雙重的：它由一個ivyResolver和一個 artifactResolver組成，其中ivyResolver負責解析ivy的模塊描述符，而artifactResolver則用于解析制品。換言之，ivyResolver用來指明需要什么，而artifactResolver則負責獲取具體的制品文件。
第一次在學習ivy的過程中看到ivy中的雙重解析器，就感覺設計非常的不錯，可以比較好的解決這方面的問題。只要維護好ivyResolver中的依賴，則整個系統中的依賴都被限制在這個范圍中。比如如果有人想用spring2.5.6之外的版本，哼哼，ivyResolver解析器會不工作的......
但是，在實際的使用過程中發現，雙重解析器的工作模式有點問題：如果目標依賴在ivyResolver中可以找到則情況正常，但是如果目標依賴在 ivyResolver中沒有定義，ivy居然會在artifactResolver的繼續查找！然后報告說依賴解析成功已下載云云，而不是我
閱讀全文
摘要: 在maven中，對于一個依賴，除了groupId，artifactId，version這三個屬性來作為標志之外，還有一個特殊的屬性可用: classifier。
ivy中依賴對應的有屬性org，name,rev，分別對應到maven中的groupId,artifactId，version.
但是dependency沒有和maven的classifier屬性相對應的屬性，因此無法表示dependency的classifier。這樣就出現問題了，比如上面的testng 的例子，在ivy中如果將對testng的依賴定義寫成上面的樣子，則解析時是無法獲取到我們想到的依賴 testng-5.10.jar的。
那么，在ivy中如何指定classifier屬性呢？
閱讀全文
摘要: 如果你已經成功的跟隨并理解了所有的教程，可能你還是需要得到更好的關于如何在現實世界中只用ivy的描述。
這里有一些有關系的鏈接.
閱讀全文
摘要: 現在你已經看到從一個已經存在的倉庫創建你自己的倉庫是如何的簡單，你可能會想知道如何處理更加復雜的情況，例如當源倉庫和目的地倉庫不遵循相同的命名約定。
當你有一個已經存在的倉庫并且希望從大量的不遵循相同的命名轉換的公共倉庫中獲益時，這個問題非常常見。或者僅僅是因為你發現你作為基礎使用的倉庫不夠一直- 為什么所有的apache commons模塊不適用org.apache.commons 組織？歷史原因。但是如果你安裝你自己的倉庫，你可能不想從歷史中蒙受損失。
幸運的是，對于這種問題ivy有一種非常強大的答復：namespaces.
閱讀全文
摘要: 在這個步驟中我們使用install任務來從maven2 倉庫安裝模塊到一個基于文件系統的倉庫。我們首先安裝一個不帶依賴的模塊，然后安裝一個帶有依賴的模塊。
閱讀全文
摘要: install任務讓你從一個倉庫復制一個模塊或者模塊集合到另一個倉庫。這對于構建和維護一個企業或者團隊倉庫非常有用。如果你不想你的團隊中的開發人員都訪問公共的maven2倉庫(例如為了控制哪些模塊可以在你的公司或者你的團隊中使用)，答復開發人員的請求來手工增加新的模塊或者新的版本在某些時候變得令人厭煩。
幸運的是install任務可以在這里提供幫助: 你可以為你的用于維護目標企業倉庫的倉庫維護構建使用特定的設置。這些設置將指向另一個倉庫(例如maven2 公共倉庫)，因此你只需要使用簡單的命令行要求ivy安裝你需要的模塊。
為了演示這個我們將首先使用個一些基本的ivy設置文件來展示它是如何工作的，然后我們將使用高級命名空間特性來演示如何在源倉庫和目標倉庫之間處理命名不匹配。
閱讀全文
摘要: 這個教程介紹ivy文件中的模塊配置的使用。ivy模塊配置事實上是一個非常重要的概念。某些人甚至告訴我使用ivy而不用ivy配置就像吃乳酪而不動就在你旁邊的Chateau Margaux 1976！
嚴肅的說，ivy中的配置可以更好的理解為你的模塊的視圖，你將可以看到在這里他們將如何被高效地使用。
閱讀全文
摘要: 在上一個教程中，你已經看到如何處理兩個簡單項目之間的依賴。
這個教程將引導你完成在一個更加復雜的環境下的ivy使用。這個教程的所有源文件在ivy發行包的src/example/multi-project下可以得到。
閱讀全文
摘要: 這個示例將舉例說明在兩個項目之間的依賴。
depender項目聲明它使用dependee 項目。我們將闡明兩個事情：
* 被獨立的項目聲明的公共類庫將被依賴的項目自動獲取
* depender項目將獲取dependee項目的"最新"版本
閱讀全文
摘要: 在一些情況下，會發生這樣的事情:你的模塊描述符(ivy文件，maven pom, ...)被放置在一個地方，而模塊的制品(jars,...)在另外一個地方。
雙重解析器用于滿足這種類型的需求，而這個教程將展示如何使用它。
閱讀全文
摘要: 這個例子演示模塊是如何被多解析器獲得的。使用多解析器在很多情況下是非常有用的，這里是一些例子：
* 來自發行的單獨的集成構建
* 為第三方模塊使用公共倉庫并且為內部模塊使用私有倉庫
* 使用一個倉庫來存儲那些在無法管理的公共倉庫里里面的不清晰的模塊
* 使用本地倉庫來暴露在一個開發人員的位置上生成的構建
在ivy中，多解析器的使用是通過一個名為解析器鏈的復合解析器來支持的。
在我們的例子中，我們將簡單的展示如何使用兩個解析器，一個在本地倉庫而另一個使用maven2倉庫。
閱讀全文
摘要: ivy綁定一些默認設置，這使得在通常環境下使用ivy很容易。這個教程，接近于參考文檔，解釋這些默認設置是什么和他們怎樣調整來滿足你的需要。
為了完整的理解設置的概念和你可以用它們做什么，我們建議閱讀其他和設置相關的教程(如Multiple Resolvers 和 Dual Resolver)或者設置文件的參考文檔。
閱讀全文
摘要: 在這個例子中，我們將看到使用ivy的一個最簡單的方式。不使用任何特殊設置，ivy將使用maven2 倉庫來解析你在ivy文件中聲明的依賴。讓我們來看一眼涉及到的文件的內容。
你將在ivy發行包的src/example/hello-ivy 目錄下找到這個教程的源文件。
閱讀全文
摘要: 學習的最佳方式是實踐！這是ivy教程將幫助你做到的，發現一些偉大的ivy特性。
這里是非常優先的教程，它甚至不需要安裝ivy，如果你已經正確安裝了ant和jdk，甚至只需要花費不到30秒的時間
閱讀全文
摘要: 在ivy中有幾個任務被認為是后解析任務(post resolve task)，并相應地共享公用行為和設置。
這些任務是：
* retrieve
* cachefileset
* cachepath
* artifactproperty (since 2.0)
* artifactreport (since 2.0)
閱讀全文
摘要: cachefileset,為配置構建一個有ivy緩存中的制品組成的ant fileset 從1.2版本起)。
這是一個后解析任務，有所有后解析任務共有的所有行為和屬性。注意這個任務不依賴retrieve，因為構建的fileset是由ivy緩存中的制品直接構成的。
閱讀全文
摘要: ln命令用于連接文件或目錄,lndir命令用于創建目錄的符號鏈接，和ln不同的是lndir會自動為源文件目錄下所有的文件和子目錄都建立對應的符號鏈接.
閱讀全文
摘要: find命令用于查找文件和目錄，任何位于參數之前的字符串都將被視為欲查找的目錄。
find 可以指定查找條件如名稱，類型，時間，文件大小，權限和所有者查找，針對多個條件進行與或非的邏輯運算。我們可以控制find的查找的行為，還可以和其他命令組合使用。
閱讀全文
摘要: 為解析過的模塊配置構建一個由在ivy 緩存(或者取決于useOrigin 設置的原始位置)中的制品組成的ant path.
閱讀全文
摘要: ls的用法: ls [OPTION]... [FILE]...
列舉文件信息(默認當前目錄), 如果-cftuvSUX或者--sort沒有設置則按照字典順序排序條目。
閱讀全文
摘要: 交付當前模塊的解析好的描述符，而且可能執行依賴的遞歸交付。
這個任務主要做兩個事情：
1. 生成一個解析好的ivy 文件
2. 執行遞歸交付
閱讀全文
工作中發現的一個非常奇怪也很有趣事情，有關MANIFEST.MF文件中的分行和空格的格式要求，分享給大家。
對于通常的MANIFEST.MF文件，一般格式是：
Class-Path: lib/a.jar lib/b.jar lib/c.jar lib/d.jar lib/e.jar lib/f.jar
在一行之內將所有的jar包路徑寫上，空格分隔即可。
但是對于一些大型的項目，因為依賴包眾多，比如大于30個，那么如果還寫在一行內，就會出現一個長度驚人的行。程序運行倒不會有任何問題，但是對于版本控制就很不友好，如增加或者減少一個依賴包，這行就會被改寫。以后compare不同版本時，只能知道這行被修改了確無法直接知道是做了什么修改，必須通過其他方式才能對比出來。
同樣的問題發生在code merge時，如果兩個分支都修改了這個文件，就必須通過手工來進行merge，而且要對照出來彼此到底改了什么，很困難而且容易出錯。
因此一個改進就是將這個文件中的依賴按照一行一個依賴的方式重寫，這樣以后修改時只會修改改依賴所在的行，很容易就對比出來具體做了哪些感動，code merge時版本控制軟件一般也很容易直接自動merge成功。
修改后的文件類似如下：
Class-Path: lib/a.jar
lib/b.jar
lib/c.jar
lib/d.jar
lib/e.jar
lib/f.jar
但是在實際操作時發生了意料之外的問題，會出現異常或者類無法找到，經檢查發現問題出現在MANIFEST.MF的格式上，MANIFEST.MF對于分行和空格是有特殊要求的：
1. 每行的最后一個jar的名稱后不容許有空格
即" lib/b.jar"在b.jar后必須回車結束本行，不能有空格，一個都不能
2. 每行的開頭必須有不少于2個空格
即" lib/b.jar"在b.jar前必須有不下兩個空格
以上兩個條件有一個不滿足都會出現問題，有點古怪。
摘要: 發行當前模塊的制品和已解析的描述符(已交付的ivy文件)。
這個任務的目的是發行當前模塊描述符和它的聲明的發行制品到倉庫中。
閱讀全文
摘要: configure任務用于通過xml設置文件來配置ivy。
閱讀全文