2006年9月21日
#
摘要: 之前遇到幾次現(xiàn)場(chǎng)故障，都是和class文件有關(guān)，比如版本不兼容造成Bad Version錯(cuò)誤之類，需要檢查class文件的編譯版本信息。 今天無意中發(fā)現(xiàn)， jdk自帶的javap 命令其實(shí)可以方便的搞定這個(gè)事情
閱讀全文
摘要: 前幾次的編碼最佳實(shí)踐系列，我們都著眼于Java代碼，今天我們換個(gè)話題，看看另外一個(gè)領(lǐng)域，和Java代碼大相徑庭的SQL。
閱讀全文
摘要: 本期的案例依然是來自實(shí)際項(xiàng)目，很尋常的代碼，卻意外遭遇傳說中的Java"內(nèi)存溢出"。
閱讀全文
摘要: 昨晚繼續(xù)折騰俺的小站http://www.javauniversity.net，準(zhǔn)備給它加上SEO支持，安裝了SEO tools模塊和相應(yīng)的依賴模塊。
結(jié)果安裝完成之后就陷入重定向循環(huán)了，每個(gè)頁(yè)面都被重定向到新地址，然后新地址再次被重定向。chrome瀏覽器會(huì)稍后報(bào)錯(cuò)說太多重定向，而ie則傻傻的一直在死循環(huán)。
閱讀全文
摘要: 折騰了兩天，終于將Java University這個(gè)站點(diǎn)開通，過程真不容易的，決定寫下來吐吐 糟，以紀(jì)念TIANCHAO和諧之光普照下P民的美好生活
閱讀全文
摘要: 這是一個(gè)來自實(shí)際項(xiàng)目的例子，在這個(gè)案例中，有同事基于jdk中的LinkedHashMap設(shè)計(jì)了一個(gè)LRUCache，為了提高性能，使用了 ReentrantReadWriteLock 讀寫鎖：寫鎖對(duì)應(yīng)put()方法，而讀鎖對(duì)應(yīng)get()方法，期望通過讀寫鎖來實(shí)現(xiàn)并發(fā)get()。
閱讀全文
摘要: 這里將要講述的是一系列的類似案例，都是在各個(gè)產(chǎn)品進(jìn)行performance tuning時(shí)被發(fā)現(xiàn)的，非常具有普適性。可以說在日常開發(fā)中，有非常大的概率遇到相同或者類似的情形，因此需要對(duì)其保持警惕以便避免陷入類似的性能問題。 我們從JAXBContext這個(gè)對(duì)象開始...
閱讀全文
摘要: 這是一個(gè)真實(shí)案例，曾經(jīng)惹出碩大風(fēng)波，故事的起因卻很簡(jiǎn)單，就是需要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的計(jì)數(shù)器，每次取值然后加1......
閱讀全文
摘要: 最近在公司內(nèi)部做了一些收集和整理的工作，關(guān)于trouble shooting和performace tuning 中遇到并解決的典型問題，做了一些內(nèi)部分享。我整理了一下，準(zhǔn)備陸續(xù)放上來分享給大家。
這些問題，單個(gè)看每個(gè)問題都不算復(fù)雜或高深，但是都是在實(shí)際項(xiàng)目開發(fā)中出現(xiàn)并一度造成困擾的，而且?guī)в幸欢ǖ钠者m性，具體表現(xiàn)為不知道這些問題的同學(xué)很容易在日常開發(fā)中中招。因此我們開了一個(gè)專題，叫做編碼最佳實(shí)踐，似乎名字起的有點(diǎn)大......
先來看看第一個(gè)，如何做compare。
閱讀全文
摘要: 今天用jetty做嵌入式web container，來做web項(xiàng)目的integration test，結(jié)果發(fā)現(xiàn)出現(xiàn)在渲染使用EL表達(dá)式的jsp頁(yè)面時(shí)出現(xiàn)異常：
javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory;
檢查了一下，發(fā)現(xiàn)javax.el.ExpressionFactory.newInstance()這個(gè)方法是EL2.2版本之后才有的方法，而在EL2.1之中是沒有這個(gè)方法的，問題很明顯：org.apache.jasper中試圖調(diào)用2.2版本的EL，當(dāng)時(shí)提供的EL的版本是2.1版本，所以解決的方式無非就是兩個(gè)，要不降低org.apache.jasper的版本，要不提升el的版本。考慮到現(xiàn)在使用的jetty已經(jīng)是最新的版本8.1.2.v20120308，因此提升EL的版本為2.2更為合適。
閱讀全文
摘要: 在jenkins上建立了一個(gè)job，通過標(biāo)準(zhǔn)的maven命令來執(zhí)行打包測(cè)試和上傳artifact到nexus倉(cāng)庫(kù)。隨后發(fā)現(xiàn)有些性能問題：sonar的job執(zhí)行時(shí)，需要重新update SCM，然后需要再次執(zhí)行test，之后才能進(jìn)行真正屬于sonar的任務(wù)如代碼檢測(cè)等。明顯update SCM 和執(zhí)行test是重復(fù)了原有job，純屬浪費(fèi)。這個(gè)重復(fù)執(zhí)行問題隨著測(cè)試案例和測(cè)試執(zhí)行時(shí)間的增加，會(huì)越來越明顯。因此需要考慮消除這里的重復(fù)問題，減少build的時(shí)間，并節(jié)約jenkins的資源。
閱讀全文
使用maven填寫依賴的時(shí)候，常會(huì)遇到需要查一下groupId/artifactId和version，有時(shí)候還要看看有沒有新的版本更新。
原來一直用http://mvnrepository.com/ 這個(gè)網(wǎng)站來搜索，最近發(fā)現(xiàn)maven官網(wǎng)也提供了類似的功能，http://search.maven.org/。
簡(jiǎn)單試用了一下search.maven.org，功能基本和mvnrepository.com相同，而且界面更簡(jiǎn)潔友好。推薦使用。
摘要: cloudfoundry是vmvare新推出來的開源PaaS平臺(tái)，我試用了一下，發(fā)現(xiàn)還是很不錯(cuò)的，申請(qǐng)過程很簡(jiǎn)單。發(fā)出來分享給大家，有需要的可以去申請(qǐng)，畢竟可以支持java的免費(fèi)的空間實(shí)在太難得了。
閱讀全文
摘要: 初學(xué)gradle，一切都還在摸索的過程中。今天剛剛試圖將之前基于ant + ivy的一個(gè)小項(xiàng)目轉(zhuǎn)移到gradle下，結(jié)果在和sonar集成時(shí)出現(xiàn)問題.
閱讀全文
摘要: 雖然easymock中提供了大量的方法來進(jìn)行參數(shù)匹配，但是對(duì)于一些特殊場(chǎng)合比如參數(shù)是復(fù)雜對(duì)象而又不能簡(jiǎn)單的通過equals()方法來比較，這些現(xiàn)有的參數(shù)匹配器就無能為力了。easymock為此提供了IArgumentMatcher 接口來讓我們實(shí)現(xiàn)自定義的參數(shù)匹配器。
閱讀全文
摘要: 在easymock中，對(duì)于mock對(duì)象的同一個(gè)方法，可以為每一次的調(diào)用定制不同的行為。在record階段easymock會(huì)精確的記錄我們錄入的行為，基于每一次的方法調(diào)用。
閱讀全文
摘要: 前面的教程中，我們看到easymock可以通過expect方法來設(shè)定mock方法的返回值或者異常，但是注意這些案例中設(shè)置的返回值都是在調(diào)用被測(cè)試的類的方法前就已經(jīng)確定下來的，即我們其實(shí)在測(cè)試類的代碼運(yùn)行前(實(shí)際是在EasyMock.replay()方法調(diào)用前)就已經(jīng)"預(yù)知"了返回結(jié)果。
但是在某些情況下，我們可能無法預(yù)知返回值，比如我們需要根據(jù)輸入的參數(shù)值來決定返回什么，而這個(gè)參數(shù)可能無法在record階段獲得。因此在mock方法中我們無法在record階段就決定應(yīng)該返回什么。
對(duì)于這種場(chǎng)景，easymock提供了IAnswer接口和andAnswer()方法來提供運(yùn)行時(shí)決定返回值或者異常的機(jī)制。
閱讀全文
摘要: easymock中提供對(duì)于類的mock功能，我們可以方便的mock這個(gè)類的某些方法，指定預(yù)期的行為以便測(cè)試這個(gè)類的調(diào)用者。這種場(chǎng)景下被mock的類在測(cè)試案例中扮演的是次要測(cè)試對(duì)象或者說依賴的角色，主要測(cè)試對(duì)象是這個(gè)mock類的調(diào)用者。但是有時(shí)候我們需要將這個(gè)測(cè)試類作為主要測(cè)試對(duì)象，我們希望這個(gè)類中的部分(通常是大部分)方法保持原有的正常行為，只有個(gè)別方法被我們mock掉以便測(cè)試。
閱讀全文
摘要: easymock中提供了非常多的方法來實(shí)現(xiàn)參數(shù)匹配，基本能滿足一般參數(shù)匹配的要求。
閱讀全文
摘要: 在創(chuàng)建mock對(duì)象的時(shí)候，我們可以命名mock對(duì)象。
命名mock對(duì)象有什么好處呢？其實(shí)就是一點(diǎn)，即在當(dāng)測(cè)試案例因?yàn)槟硞€(gè)mock對(duì)象的狀態(tài)或行為不符合要求而失敗的時(shí)候，在異常信息里面可以輸出這個(gè)mock對(duì)象的名稱。
閱讀全文
摘要: 對(duì)于mock對(duì)象上的mock方法的調(diào)用,easymock支持指定次數(shù)，默認(rèn)為1.同時(shí)easymock提供了其他的方法，用于指定具體調(diào)用次數(shù)或者放寬調(diào)用次數(shù)檢驗(yàn)。
閱讀全文
摘要: easymock并不是萬能的，在使用easymock時(shí)有一些限制需要注意。
閱讀全文
摘要:
前面教程中有個(gè)章節(jié)討論到mock和stub的概念差別，一般來說easymock如其名所示，主要是用來做mock用的，但是easymock中也提供有對(duì)stub的支持, 主要體現(xiàn)在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
閱讀全文
大家都知道sonar是個(gè)好東東，在有CI支持的情況下，使用好了可以非常好的控制代碼的質(zhì)量，諸如代碼覆蓋率，代碼規(guī)則檢查等。
而解決violation的辦法，除了正統(tǒng)的修改代碼來滿足規(guī)則外，還有一個(gè)變通的方法， NOSONAR。這個(gè)標(biāo)記本意是在一些特殊情況，有不得已的理由不得不違反規(guī)則，為了避免sonar繼續(xù)報(bào)錯(cuò)而不得已做了一個(gè)"變通"。
NOSONAR本意雖好，但要是有人濫用，變通就會(huì)變成取巧，因?yàn)榻鉀Qsonar violation的最簡(jiǎn)單的方法，就是直接NOSONAR！
當(dāng)問題很簡(jiǎn)單時(shí)，一般人都會(huì)選擇正常的方式修改代碼，如果只是舉手之勞基本上還是能遵守規(guī)則的。但是當(dāng)問題復(fù)雜時(shí)，或者說當(dāng)解決問題不再是舉手之勞時(shí)，每個(gè)人都要受到NOSONAR的誘惑。而NOSONAR的底線在哪里？沒有人定義，沒有人檢測(cè)，自然不會(huì)每個(gè)人都堅(jiān)守，NOSONAR的底線隨著一個(gè)一個(gè)的NOSONAR慢慢的在降低。退五十步的人，是沒有資格笑百步的。
返回到現(xiàn)實(shí)代碼中，不知道是大家都沒有頂住誘惑，還是說我們開啟的規(guī)則不大合理，總之越來越頻繁的在代碼中看到NOSONAR了，雖然還沒有到泛濫的地步，但是已經(jīng)讓我有些不安了。簡(jiǎn)單搜索了一下剛才讓我感覺到很多NOSONAR的project，結(jié)果是58個(gè)。
更糟糕的是，每個(gè)NOSONAR后面都不會(huì)帶有注釋說明為什么要NOSONAR，因此一個(gè)個(gè)飛舞的NOSONAR就變成了一個(gè)個(gè)謎團(tuán)。想知道為什么要NOSONAR嗎？恩，你猜......
我沒有辦法去檢查這個(gè)58個(gè)NOSONAR是不是都合理的，都站得住腳的。出于程序員的習(xí)慣，對(duì)于一切不可確認(rèn)性都報(bào)以懷疑的眼光和質(zhì)疑的姿態(tài)，我總覺得這58個(gè)NOSONAR讓我總是沒有底，每次我看到sonar上100%的規(guī)則檢測(cè)通過率時(shí)，我總是禁不住在心里浮現(xiàn)NOSONAR的字樣。
好吧，我承認(rèn)，我是個(gè)心里有些陰暗的家伙......
摘要: 在easymock的使用過程中，當(dāng)創(chuàng)建mock對(duì)象時(shí)，我們會(huì)遇到 strict mock和nice mock的概念。上述的測(cè)試案例驗(yàn)證了strict mock和nice mock的基本使用，對(duì)于同一個(gè)mock對(duì)象，strict模式下多個(gè)方法之間的調(diào)用順序在record階段和replay階段下是需要保持一致的。但是故事并不是到此結(jié)束，更有意思的內(nèi)容在后面：如果出現(xiàn)多個(gè)mock對(duì)象，那么這些不同mock對(duì)象的方法之間，他們的調(diào)用順序是否檢測(cè)？普通mock和nice mock模式下自然是不會(huì)檢測(cè)順序，但是strict模式下呢？
閱讀全文
摘要: IMocksControl接口容許創(chuàng)建多個(gè)mock對(duì)象，這些創(chuàng)建的對(duì)象自動(dòng)關(guān)聯(lián)到這個(gè)mocksControl實(shí)例上，以后再調(diào)用replay()/verify()/reset()時(shí)就不需要逐個(gè)列舉出每個(gè)mock對(duì)象。當(dāng)mock對(duì)象比較多，尤其是原有代碼上新增mock 對(duì)象時(shí)非常方便。
閱讀全文
摘要: 前面的例子中，mock的對(duì)象都是基于interface，雖然說我們總是強(qiáng)調(diào)要面對(duì)接口編程，而不要面對(duì)實(shí)現(xiàn)，但是實(shí)際開發(fā)中不提取interface而直接使用class的場(chǎng)景非常之多。尤其是一些當(dāng)前只有一個(gè)明確實(shí)現(xiàn)而看不到未來擴(kuò)展的類，是否應(yīng)該提取interface或者說是否應(yīng)該現(xiàn)在就提取interface，總是存在爭(zhēng)論。
這種情況下，我們就會(huì)面臨主要測(cè)試對(duì)象依賴到一個(gè)具體類而不是interface的情況，easymock中通過class extension 來提供對(duì)class mocking的支持。
閱讀全文
摘要: 關(guān)于easymock的典型使用方式，在easymock的官網(wǎng)文檔中，有非常詳盡的講解，文檔地址為 http://easymock.org/EasyMock3_0_Documentation.html，文檔的開頭一部分內(nèi)容都是easymock中最基本的使用介紹，雖然是英文，但是非常容易看懂，適用新學(xué)者入門。
這里只羅列一些簡(jiǎn)單的常用功能。
閱讀全文
摘要: record-replay-verify 模型容許記錄mock對(duì)象上的操作然后重演并驗(yàn)證這些操作。這是目前mock框架領(lǐng)域最常見的模型，幾乎所有的mock框架都是用這個(gè)模型，有些是現(xiàn)實(shí)使用如easymock，有些是隱式使用如jmockit。
record-replay-verify 模型非常好的滿足了大多數(shù)測(cè)試場(chǎng)景的需要：先指定測(cè)試的期望，然后執(zhí)行測(cè)試，再驗(yàn)證期望是否被滿足。這個(gè)模型簡(jiǎn)單直接，易于實(shí)現(xiàn)，也容易被開發(fā)人員理解和接受，因此被各個(gè)mock框架廣泛使用。
閱讀全文
摘要: 在單元測(cè)試中，通常我們都會(huì)有一個(gè)明確的測(cè)試對(duì)象，我們測(cè)試的主要目的就是為了驗(yàn)證這個(gè)類的工作如我們預(yù)期。
閱讀全文
摘要: easymock是目前java mock 工具中比較流行的工具，這個(gè)教程將系統(tǒng)的介紹easymock的使用。
主要內(nèi)容來自easymock的官網(wǎng)教程，針對(duì)日常使用進(jìn)行了一些篩選和補(bǔ)充，另外增加一些個(gè)人的理解和認(rèn)識(shí)。
另外考慮到網(wǎng)絡(luò)上已有不少分散的教程，我將適當(dāng)?shù)逆溄舆M(jìn)來。
教程的內(nèi)容將在隨后逐漸添加，目前計(jì)劃的目錄如下，相應(yīng)內(nèi)容完成之后我將逐個(gè)更新此文的鏈接。
閱讀全文
近期發(fā)現(xiàn)一個(gè)問題，hudson執(zhí)行任務(wù)時(shí)，經(jīng)常不能獲取到最新的代碼，從而導(dǎo)致出現(xiàn)各種問題。
日常開發(fā)中的典型例子：發(fā)現(xiàn)一個(gè)bug，修改代碼，本地測(cè)試通過，提交代碼到subversion，手工激活hudson構(gòu)建，原本期望hudson獲取到剛剛提交的代碼并測(cè)試/打包/發(fā)布。結(jié)果事與愿違，測(cè)試的結(jié)果發(fā)現(xiàn)剛剛做出的修改似乎沒有生效。正費(fèi)解之時(shí)，再執(zhí)行一次hudson構(gòu)建，又成功了...
經(jīng)歷過幾次上述蹊蹺遭遇之后，發(fā)現(xiàn)這個(gè)問題不是偶然。之后檢查hudson的日志，發(fā)現(xiàn)問題的發(fā)現(xiàn)在最開始update / check out subversion代碼時(shí)，明明已經(jīng)提交的代碼，hudson做update / check out時(shí)，居然沒有update / check out下來！顯示的subversion版本號(hào)也和subversion上實(shí)際的最新版本不一致，hudson總是要小一些，換言之，hudson update / check out的代碼要比當(dāng)前最新代碼老一些。
google一番，發(fā)現(xiàn)這個(gè)問題之前就有人遭遇過，hudson上甚至已經(jīng)有了好幾個(gè)關(guān)于這個(gè)問題的bug，比如 http://issues.hudson-ci.org/browse/HUDSON-1241 "force using HEAD SVN version for build"。問題的根源在于hudson 獲取subversion代碼的方式，hudson是通過時(shí)間戳的方式來獲取代碼，而不是我們一般認(rèn)為的"最新代碼"即"HEAD"。這種方式通常沒有問題，因?yàn)楂@取當(dāng)前時(shí)間戳，然后要求update / checkout這個(gè)時(shí)間戳前的代碼，理論上也是可以拿到最新代碼的。
但是，如果hudson所在的服務(wù)器和subversion服務(wù)器時(shí)間不一致，這個(gè)機(jī)制就會(huì)出現(xiàn)問題:
我們假設(shè)subversion服務(wù)器的時(shí)間是準(zhǔn)確的，再假設(shè)當(dāng)時(shí)時(shí)間是15:10分，開發(fā)人員A提交代碼，subversion上當(dāng)前這個(gè)最新提交的代碼時(shí)間戳為15:10:00。然后開發(fā)人員A手工激活hudson進(jìn)行構(gòu)建。hudson在15:10:20時(shí)開始check out代碼。如果hudson時(shí)間無誤，則hudson會(huì)發(fā)出請(qǐng)求說要求獲取時(shí)間戳在15:10:20之前的代碼，這樣這個(gè)實(shí)際提交時(shí)間為15:10:00的新代碼就可以如期的被check out。但是如果hudson的時(shí)鐘有誤，由于某些原因?qū)е聲r(shí)鐘偏慢2分鐘，即在hudson上，"當(dāng)前時(shí)間"為"15:08:20"，則hudson獲取代碼的請(qǐng)求為:獲取時(shí)間戳為15:08:20之前的代碼，此時(shí)時(shí)間戳為15:10:00的新代碼就無法checkout。
幾分鐘之后，疑惑的開發(fā)人員A再次激活hudson再次構(gòu)建，假設(shè)此時(shí)時(shí)間時(shí)間是15:15:00，hudson慢兩分鐘為15:13:00。此時(shí)hudson發(fā)出請(qǐng)求: 獲取時(shí)間戳為15:13:00之前的代碼, 因此實(shí)際提交時(shí)間為15:10:00的新代碼可以正常checkout，問題又在不知不覺被回避了。
總結(jié)說，hudson 獲取代碼的機(jī)制不是我們直覺中的獲取最新代碼(即subversion中HEAD checkout)，而是基于時(shí)間戳。由于這個(gè)方式通常如HEAD般工作，因此我們總是容易誤解為是獲取最新代碼。當(dāng)hudson的時(shí)鐘晚于subversion時(shí)，悲劇就出現(xiàn)了。
對(duì)這個(gè)問題，有幾點(diǎn)疑惑：
1. 不明白為什么hudson不采用最直接最簡(jiǎn)單最容易被人理解最不容易出誤解的HEAD checkout，而要基于時(shí)間戳
2. 這個(gè)問題很早就發(fā)生了，上面提到的bug 08年就被人提出, "Created: 31/Jan/08 05:37 AM Updated: 01/Jul/10 11:06 AM"，三年了類似的bug被多次提出，但是就是始終沒有修復(fù)。
修復(fù)的方式很簡(jiǎn)單，就改一個(gè)類的一行代碼
in Class: hudson.scm.SubversionSCM
line 377:
final SVNRevision revision = SVNRevision.create(timestamp);
replace to:
final SVNRevision revision = SVNRevision.HEAD;
hudson拒絕修復(fù)的理由是什么？
Maven 3.0 的第一個(gè)RC版本終于發(fā)布了，下面是sonatype給出的發(fā)布信息：
Maven 在apache上的頁(yè)面目前還沒有放出RC1版本。下面是關(guān)于mavne3.*版本相對(duì)于2.* 版本的改進(jìn)列表：
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
PS: 坦言說，改進(jìn)很少，尤其沒有大的功能改進(jìn)，有點(diǎn)失望。
修訂：上面的URL是兼容性列表，因此看起來和2.*差別不大，是我理解錯(cuò)了，抱歉。
摘要: 最新版本的confluence 3.3.1 linux 安裝筆記。
閱讀全文
摘要: 之前安裝的fisheye2.2.1，破解不是很好用，最近看到fisheye2.3.6版本有出新的破解方式，特地嘗試了一下，成功安裝。現(xiàn)在將過程簡(jiǎn)單分享給大家。
閱讀全文
摘要: 作為測(cè)試的基本概念，在開發(fā)測(cè)試中經(jīng)常遇到mock和stub。之前認(rèn)為自己對(duì)這兩個(gè)概念已經(jīng)很明白了，但是當(dāng)決定要寫下來并寫清楚以便能讓不明白的人也能弄明白，似乎就很有困難。
試著寫下此文，以檢驗(yàn)自己是不是真的明白mock和stub。
閱讀全文
講個(gè)笑話吧，關(guān)于"keep it simple"
這其實(shí)是個(gè)真實(shí)的故事，發(fā)生在兩年前，當(dāng)我從上一家公司離職時(shí)。
當(dāng)時(shí)我移交了一個(gè)重要模塊，后來不久，記不清了，大概一兩個(gè)月后吧，有關(guān)系不錯(cuò)的同事告訴我說：某某人大肆宣揚(yáng)，***模塊我只找個(gè)了***的人，*天就接手了，云云。
言下之意自不必說。
而我，則將上述評(píng)論視為對(duì)自己的嘉獎(jiǎng)，深以為榮。
*******************************************************************************
為了大家能看懂這個(gè)笑話，羅嗦一點(diǎn)介紹兩個(gè)背景故事：
1. 最驕傲的事
工作9年了，回首看最令自己驕傲的事情，就是在07年的夏天，加班加點(diǎn)的工作了1個(gè)半月，將上述模塊的新需求完成。開發(fā)模式是我最喜愛的TDD + 持續(xù)重構(gòu)，完備的unit測(cè)試案例覆蓋。后面測(cè)試中，3位負(fù)責(zé)測(cè)試同事用了三天的時(shí)間，測(cè)試完成所有的測(cè)試案例，全部一次性通過，沒有一個(gè)bug，哪怕是小bug。
此記錄本人之后兩年中一直試圖復(fù)制，至今沒有成功。
2. 荒謬的問題
發(fā)生在離職做上述模塊移交時(shí)，被接收人問了一個(gè)問題：項(xiàng)目代碼里面，test目錄下是什么東西啊？
import junit.***, extends TestCase...
無言以對(duì)。
摘要: Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)為Tokyo Tyrant的基礎(chǔ)教程。
閱讀全文
摘要:
Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)介紹Tokyo Tyrant的遠(yuǎn)程數(shù)據(jù)庫(kù)API，Lua擴(kuò)展和協(xié)議。部分細(xì)節(jié)內(nèi)容沒有翻譯。
閱讀全文
摘要:
Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)介紹Tokyo Tyrant的客戶端程序。
閱讀全文
摘要: Tokyo Tyrant基本規(guī)范，翻譯自tt官網(wǎng)，地址為http://fallabs.com/tokyotyrant/spex.html。
本節(jié)介紹Tokyo Tyrant的服務(wù)器程序。
閱讀全文
摘要: Tokyo Tyrant基本規(guī)范，翻譯自tt官網(wǎng)，地址為http://fallabs.com/tokyotyrant/spex.html。
本節(jié)介紹Tokyo Tyrant的基本知識(shí)和安裝方法。
閱讀全文
摘要: Solr是一個(gè)基于Lucene java庫(kù)的企業(yè)級(jí)搜索服務(wù)器，本文記錄了solr的安裝過程，版本為最新的1.4.1。
閱讀全文
摘要: Tokyo Tyrant是目前評(píng)價(jià)最高的key-value數(shù)據(jù)庫(kù)之一，本文記錄在linux(suse11)上的安裝過程。
閱讀全文
摘要: 一直在使用easymock作為mock工具，但是easymock有一個(gè)一直令我極其惱火的地方：easymock將interface和class的mock區(qū)分開，給出了針對(duì)interface mock的easyMock和針對(duì)class mock的easyMock class extension。兩種mock被嚴(yán)格區(qū)分開，連jar包都是兩個(gè)，使用時(shí)不能混用，比如不能用easymock (非class extension)來mock class。
easymock已經(jīng)發(fā)布了新的3.0版本，該版本的主要改進(jìn)就是消除上述的問題，新版本中可以直接mock class，不再?gòu)?qiáng)制使用easyMock class extension。
強(qiáng)烈推薦還在使用2.*的朋友們升級(jí)到3.0版本。
閱讀全文
摘要: 有遇到類似的TortoiseSVN / subversive 信息無法識(shí)別的問題的朋友，可以這個(gè)方法。
閱讀全文
摘要: sonar 安裝配置筆記, 基于SUSE SLSE11, mysql.
閱讀全文
摘要: 近期自己折騰自己，放著正統(tǒng)的maven + junit不用，卻準(zhǔn)備用ant + ivy 替代maven做依賴管理，用testng替代junit做單元測(cè)試。
閱讀全文
摘要: 眾所周知，對(duì)于高動(dòng)態(tài)高可擴(kuò)展的應(yīng)用，OSGI是一個(gè)非常好的平臺(tái)。但是，也因此增加了復(fù)雜性，開發(fā)中對(duì)service的依賴變得復(fù)雜。這也是 service的關(guān)系管理成為OSGI中一個(gè)非常重要的部分，我們來看看OSGI中service依賴關(guān)系管理的方式。篇幅原因，只關(guān)注發(fā)展歷程，不具體介紹每個(gè)方式的詳細(xì)實(shí)現(xiàn)細(xì)節(jié)。
概括的說，目前在OSGI中主要有以下幾種service依賴關(guān)系管理的方法：
1. Service listener
2. Service binder
3. Dependency Manager
4. Declarative Services
5. iPOJO
6. blueprint
閱讀全文
摘要: 當(dāng)時(shí)實(shí)際上，我們?cè)跈z查ThreadDeath的調(diào)用信息時(shí)，說明這個(gè)出現(xiàn)init()錯(cuò)誤的filter還是被glassfish正常調(diào)用去執(zhí)行doFilter()方法，這里和j2ee API的要求是不符合的。有點(diǎn)奇怪的是，glassfish一向是以嚴(yán)格遵循j2ee規(guī)范而著稱，居然在這里一反常態(tài)。
而更令人 郁悶的是，glassfish在處理這個(gè)有filter初始化出現(xiàn)ServletException異常的webapp時(shí)的前后表現(xiàn)：首先這個(gè) webapp的啟動(dòng)沒有問題，狀態(tài)正常。filter也被認(rèn)為可以正常工作并加入了filter鏈。webapp中的功能正常，可以正常的接收請(qǐng)求并轉(zhuǎn)發(fā)給內(nèi)容業(yè)務(wù)處理模塊。從這些跡象看這個(gè)webapp基本沒有問題。但是后面glassfish卻莫名其妙的認(rèn)定，“this web application instance has been stopped already”，從而以ThreadDeath這種非常規(guī)的error來報(bào)錯(cuò)。
閱讀全文
摘要: 對(duì)比最近遇到的兩個(gè)事情，明顯感覺sun有力不從心或者心不在焉的感覺，oracle對(duì)sun收購(gòu)的負(fù)面影響至少在開源社區(qū)方面是顯而易見的，個(gè)人甚至懷疑oracle正在逐漸放棄之前sun一直努力支撐的開源社區(qū)。
閱讀全文
摘要: 剛剛鄙視完sun，繼續(xù)performance tuning，結(jié)果又發(fā)現(xiàn)問題。
有點(diǎn)懷疑metro是不是根本就沒有做過性能測(cè)試，我們的測(cè)試場(chǎng)景，openESB下通過bepl調(diào)用4個(gè)我們稱為common service的webservice，目前大概做到1200個(gè)tps，算下來common service的webservice的tps大概是1200*4 = 5K附近，上面的問題就非常明顯，之前tps沒有上去前沒有這么嚴(yán)重。
可以參考我之前的一個(gè)blog， http://www.tkk7.com/aoxj/archive/2010/04/29/319706.html，在解決這里提到的http long connection 和 TIME_AIT的問題之前，我們的tps比較低，cpu壓不上去，當(dāng)時(shí)好像這個(gè)問題不明顯。后來搞定之后tps上來了才暴露出來。
考慮上一個(gè)blog中 == 比較無效導(dǎo)致cache失效的bug，我對(duì)metro的代碼質(zhì)量真是很沒有信息。按說這樣的大型項(xiàng)目，release之前怎么也要做做壓力測(cè)試，穩(wěn)定性測(cè)試之
閱讀全文
摘要: 依然是近期工作中發(fā)現(xiàn)的問題，真實(shí)案例，寫下來分享給大家。
總結(jié)：用 == 來比較非enum或者類型安全枚舉的對(duì)象實(shí)例，這種錯(cuò)誤一般只有初學(xué)者才犯，萬萬沒有想到，能在metro這樣級(jí)別的代碼中也能出現(xiàn)。無限感嘆啊，再次援引同事的評(píng)語作為本文的結(jié)束語：
sun的程序員也是程序員啊！
閱讀全文
摘要: 近日做性能調(diào)優(yōu)，主要是針對(duì)web service，運(yùn)行于glassfish之上
最終的結(jié)果，還是比較理想的，修改了兩個(gè)參數(shù)之后，cpu終于壓上去了，tps也有了巨大的提升，而且TIME_WAIT的連接也大為減少。
但是這兩個(gè)max connections參數(shù)的名稱，注釋和實(shí)際測(cè)試中的效果，都有名不副實(shí)的感覺，令人極度困惑。
閱讀全文
摘要: fisheye2.2.1 & Crucible 2.2.1 安裝配置筆記。
閱讀全文
摘要: 今天，嘗試使用slf4j + logback的黃金組合，結(jié)果發(fā)現(xiàn)有點(diǎn)問題，slf4j和logback的最新版本不兼容。當(dāng)然slf4j是1.6.0-RC0，正式發(fā)布時(shí) logback應(yīng)該會(huì)跟進(jìn)發(fā)布新的版本吧。
閱讀全文
摘要: 這是一個(gè)真實(shí)案例，本周在工作中發(fā)現(xiàn)的，案例情況比較極端，因此顯得很滑稽很搞笑。但是深入一下，還是有些東西值得思考：
下一次，如果我面對(duì)一個(gè)函數(shù)/接口，要求傳入一個(gè)大對(duì)象，我手頭只有一個(gè)pk，還有一個(gè)現(xiàn)成的函數(shù)可以一行代碼就搞定查詢，我要如何才能擋住誘惑？
閱讀全文
摘要:
在SUSE SLES11 下安裝好tomcat6后，考慮方便需要設(shè)置tomcat為開機(jī)自動(dòng)運(yùn)行。
找到tomcat官方的安裝文檔 http://tomcat.apache.org/tomcat-6.0-doc/setup.html，按照要求安裝，中間發(fā)現(xiàn)有些問題，記錄下來備忘。
閱讀全文
摘要: 這段時(shí)間簡(jiǎn)單的試用了一下jira，非常滿意。準(zhǔn)備作為個(gè)人之后開發(fā)的首選缺陷管理工具，但是當(dāng)時(shí)采用的是windows的全集成安裝方式，因此考慮在linux上正式的安裝一下，同時(shí)將數(shù)據(jù)庫(kù)換成mysql。
雖然最后的結(jié)果不大好，不過上面的這個(gè)安裝過程，已經(jīng)遠(yuǎn)比當(dāng)前google上能找到的資料要多了。如果其他朋友有打算用jira4 + resin4 + mysql的，可以稍微參考，少走彎路。如果最后能安裝成功正確使用，希望能告知正確的安裝方法，謝謝！
閱讀全文
摘要: 前面的blog有提到，在選擇CMS系統(tǒng)時(shí)試用java版本的magnolia，結(jié)果很失望的放棄了。
重新將目光投向php + mysql的傳統(tǒng)CMS，我選擇了drupal，下面是drupal的安裝配置筆記。
閱讀全文
摘要: SUSE SLES11 上安裝配置mysql的筆記，分享并備忘。
閱讀全文
摘要: 最近想找個(gè)cms系統(tǒng)來用用，做點(diǎn)簡(jiǎn)單的東西，因?yàn)樽约罕容^熟悉java，因此考慮試試java版本的cms系統(tǒng)先，記得之前hibernate網(wǎng)站改版，是換了一個(gè)java版本的cms的，特地找過去看了一下，magnolia，google了一下似乎好評(píng)還不少。于是下載下來開始研究。
延續(xù)這些年的習(xí)慣，安裝過程一定要詳細(xì)記錄下來，避免日后再次安裝時(shí)浪費(fèi)時(shí)間，呵呵。
試用的結(jié)果很不好，還沒有正式開始使用就決定放棄，原因請(qǐng)見下文。
閱讀全文
摘要: 安裝SUSE sles11的過程記錄，分享給有類似需要的朋友，同時(shí)備忘。
閱讀全文
摘要: 有兩年多沒有使用resin了，最近打算在機(jī)器上安裝一個(gè)web container跑點(diǎn)java web app，同時(shí)也可能需要支持php，原本打算用apache + tomcat,apache可以加載php模塊來提供php支持，tomcat作為java web container。但突然想到resin，似乎是可以直接支持php的，而且resin的速度也是稍微快于tomcat，于是跑到resin的官網(wǎng)看了一下，恩，新出了4.0版本(慚愧，兩年前用的是3.0或者3.1)。
決定用resin試試，老朋友了。但是在安裝過程中，發(fā)現(xiàn)了一系列問題，尤其是設(shè)置開機(jī)自動(dòng)啟動(dòng)，記錄下來提供大家參考。
閱讀全文
摘要: 在windows上安裝jira 4.0.2的簡(jiǎn)單過程記錄，備忘。
閱讀全文
摘要: 從網(wǎng)上找到的一個(gè)設(shè)計(jì)模式快速參考，感覺做的非常的好，分享給大家。
閱讀全文
摘要: 在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規(guī)范的要求，一般不容許直接啟動(dòng)線程。因此在常見的異步/并行任務(wù)執(zhí)行上，會(huì)遭遇到比普通javase程序更多的麻煩。
閱讀全文
摘要: 這是近期工作中遇到的一個(gè)問題，cxf在glassfish下timeout設(shè)置出現(xiàn)問題，進(jìn)而引發(fā)的關(guān)于classloader, JAX-WS的一些小故事，很驚訝的發(fā)現(xiàn)cxf在這種情況下根本沒有辦法運(yùn)行于glassfish平臺(tái)。
關(guān)鍵字：glassfish, cxf, classloader, JAX-WS, metro。
閱讀全文
摘要: 如題，osgi 資料收集貼，隨時(shí)收集，隨時(shí)更新。
閱讀全文
摘要: 在討論這個(gè)問題前，先簡(jiǎn)單的介紹一下雙重解析器的工作原理：顧名思義，雙重解析是雙重的：它由一個(gè)ivyResolver和一個(gè) artifactResolver組成，其中ivyResolver負(fù)責(zé)解析ivy的模塊描述符，而artifactResolver則用于解析制品。換言之，ivyResolver用來指明需要什么，而artifactResolver則負(fù)責(zé)獲取具體的制品文件。
第一次在學(xué)習(xí)ivy的過程中看到ivy中的雙重解析器，就感覺設(shè)計(jì)非常的不錯(cuò)，可以比較好的解決這方面的問題。只要維護(hù)好ivyResolver中的依賴，則整個(gè)系統(tǒng)中的依賴都被限制在這個(gè)范圍中。比如如果有人想用spring2.5.6之外的版本，哼哼，ivyResolver解析器會(huì)不工作的......
但是，在實(shí)際的使用過程中發(fā)現(xiàn)，雙重解析器的工作模式有點(diǎn)問題：如果目標(biāo)依賴在ivyResolver中可以找到則情況正常，但是如果目標(biāo)依賴在 ivyResolver中沒有定義，ivy居然會(huì)在artifactResolver的繼續(xù)查找！然后報(bào)告說依賴解析成功已下載云云，而不是我
閱讀全文
摘要: 在maven中，對(duì)于一個(gè)依賴，除了groupId，artifactId，version這三個(gè)屬性來作為標(biāo)志之外，還有一個(gè)特殊的屬性可用: classifier。
ivy中依賴對(duì)應(yīng)的有屬性org，name,rev，分別對(duì)應(yīng)到maven中的groupId,artifactId，version.
但是dependency沒有和maven的classifier屬性相對(duì)應(yīng)的屬性，因此無法表示dependency的classifier。這樣就出現(xiàn)問題了，比如上面的testng 的例子，在ivy中如果將對(duì)testng的依賴定義寫成上面的樣子，則解析時(shí)是無法獲取到我們想到的依賴 testng-5.10.jar的。
那么，在ivy中如何指定classifier屬性呢？
閱讀全文
摘要: 如果你已經(jīng)成功的跟隨并理解了所有的教程，可能你還是需要得到更好的關(guān)于如何在現(xiàn)實(shí)世界中只用ivy的描述。
這里有一些有關(guān)系的鏈接.
閱讀全文
摘要: 現(xiàn)在你已經(jīng)看到從一個(gè)已經(jīng)存在的倉(cāng)庫(kù)創(chuàng)建你自己的倉(cāng)庫(kù)是如何的簡(jiǎn)單，你可能會(huì)想知道如何處理更加復(fù)雜的情況，例如當(dāng)源倉(cāng)庫(kù)和目的地倉(cāng)庫(kù)不遵循相同的命名約定。
當(dāng)你有一個(gè)已經(jīng)存在的倉(cāng)庫(kù)并且希望從大量的不遵循相同的命名轉(zhuǎn)換的公共倉(cāng)庫(kù)中獲益時(shí)，這個(gè)問題非常常見。或者僅僅是因?yàn)槟惆l(fā)現(xiàn)你作為基礎(chǔ)使用的倉(cāng)庫(kù)不夠一直- 為什么所有的apache commons模塊不適用org.apache.commons 組織？歷史原因。但是如果你安裝你自己的倉(cāng)庫(kù)，你可能不想從歷史中蒙受損失。
幸運(yùn)的是，對(duì)于這種問題ivy有一種非常強(qiáng)大的答復(fù)：namespaces.
閱讀全文
摘要: 在這個(gè)步驟中我們使用install任務(wù)來從maven2 倉(cāng)庫(kù)安裝模塊到一個(gè)基于文件系統(tǒng)的倉(cāng)庫(kù)。我們首先安裝一個(gè)不帶依賴的模塊，然后安裝一個(gè)帶有依賴的模塊。
閱讀全文
摘要: install任務(wù)讓你從一個(gè)倉(cāng)庫(kù)復(fù)制一個(gè)模塊或者模塊集合到另一個(gè)倉(cāng)庫(kù)。這對(duì)于構(gòu)建和維護(hù)一個(gè)企業(yè)或者團(tuán)隊(duì)倉(cāng)庫(kù)非常有用。如果你不想你的團(tuán)隊(duì)中的開發(fā)人員都訪問公共的maven2倉(cāng)庫(kù)(例如為了控制哪些模塊可以在你的公司或者你的團(tuán)隊(duì)中使用)，答復(fù)開發(fā)人員的請(qǐng)求來手工增加新的模塊或者新的版本在某些時(shí)候變得令人厭煩。
幸運(yùn)的是install任務(wù)可以在這里提供幫助: 你可以為你的用于維護(hù)目標(biāo)企業(yè)倉(cāng)庫(kù)的倉(cāng)庫(kù)維護(hù)構(gòu)建使用特定的設(shè)置。這些設(shè)置將指向另一個(gè)倉(cāng)庫(kù)(例如maven2 公共倉(cāng)庫(kù))，因此你只需要使用簡(jiǎn)單的命令行要求ivy安裝你需要的模塊。
為了演示這個(gè)我們將首先使用個(gè)一些基本的ivy設(shè)置文件來展示它是如何工作的，然后我們將使用高級(jí)命名空間特性來演示如何在源倉(cāng)庫(kù)和目標(biāo)倉(cāng)庫(kù)之間處理命名不匹配。
閱讀全文
摘要: 這個(gè)教程介紹ivy文件中的模塊配置的使用。ivy模塊配置事實(shí)上是一個(gè)非常重要的概念。某些人甚至告訴我使用ivy而不用ivy配置就像吃乳酪而不動(dòng)就在你旁邊的Chateau Margaux 1976！
嚴(yán)肅的說，ivy中的配置可以更好的理解為你的模塊的視圖，你將可以看到在這里他們將如何被高效地使用。
閱讀全文
摘要: 在上一個(gè)教程中，你已經(jīng)看到如何處理兩個(gè)簡(jiǎn)單項(xiàng)目之間的依賴。
這個(gè)教程將引導(dǎo)你完成在一個(gè)更加復(fù)雜的環(huán)境下的ivy使用。這個(gè)教程的所有源文件在ivy發(fā)行包的src/example/multi-project下可以得到。
閱讀全文
摘要: 這個(gè)示例將舉例說明在兩個(gè)項(xiàng)目之間的依賴。
depender項(xiàng)目聲明它使用dependee 項(xiàng)目。我們將闡明兩個(gè)事情：
* 被獨(dú)立的項(xiàng)目聲明的公共類庫(kù)將被依賴的項(xiàng)目自動(dòng)獲取
* depender項(xiàng)目將獲取dependee項(xiàng)目的"最新"版本
閱讀全文
摘要: 在一些情況下，會(huì)發(fā)生這樣的事情:你的模塊描述符(ivy文件，maven pom, ...)被放置在一個(gè)地方，而模塊的制品(jars,...)在另外一個(gè)地方。
雙重解析器用于滿足這種類型的需求，而這個(gè)教程將展示如何使用它。
閱讀全文
摘要: 這個(gè)例子演示模塊是如何被多解析器獲得的。使用多解析器在很多情況下是非常有用的，這里是一些例子：
* 來自發(fā)行的單獨(dú)的集成構(gòu)建
* 為第三方模塊使用公共倉(cāng)庫(kù)并且為內(nèi)部模塊使用私有倉(cāng)庫(kù)
* 使用一個(gè)倉(cāng)庫(kù)來存儲(chǔ)那些在無法管理的公共倉(cāng)庫(kù)里里面的不清晰的模塊
* 使用本地倉(cāng)庫(kù)來暴露在一個(gè)開發(fā)人員的位置上生成的構(gòu)建
在ivy中，多解析器的使用是通過一個(gè)名為解析器鏈的復(fù)合解析器來支持的。
在我們的例子中，我們將簡(jiǎn)單的展示如何使用兩個(gè)解析器，一個(gè)在本地倉(cāng)庫(kù)而另一個(gè)使用maven2倉(cāng)庫(kù)。
閱讀全文
摘要: ivy綁定一些默認(rèn)設(shè)置，這使得在通常環(huán)境下使用ivy很容易。這個(gè)教程，接近于參考文檔，解釋這些默認(rèn)設(shè)置是什么和他們?cè)鯓诱{(diào)整來滿足你的需要。
為了完整的理解設(shè)置的概念和你可以用它們做什么，我們建議閱讀其他和設(shè)置相關(guān)的教程(如Multiple Resolvers 和 Dual Resolver)或者設(shè)置文件的參考文檔。
閱讀全文
摘要: 在這個(gè)例子中，我們將看到使用ivy的一個(gè)最簡(jiǎn)單的方式。不使用任何特殊設(shè)置，ivy將使用maven2 倉(cāng)庫(kù)來解析你在ivy文件中聲明的依賴。讓我們來看一眼涉及到的文件的內(nèi)容。
你將在ivy發(fā)行包的src/example/hello-ivy 目錄下找到這個(gè)教程的源文件。
閱讀全文
摘要: 學(xué)習(xí)的最佳方式是實(shí)踐！這是ivy教程將幫助你做到的，發(fā)現(xiàn)一些偉大的ivy特性。
這里是非常優(yōu)先的教程，它甚至不需要安裝ivy，如果你已經(jīng)正確安裝了ant和jdk，甚至只需要花費(fèi)不到30秒的時(shí)間
閱讀全文
摘要: 在ivy中有幾個(gè)任務(wù)被認(rèn)為是后解析任務(wù)(post resolve task)，并相應(yīng)地共享公用行為和設(shè)置。
這些任務(wù)是：
* retrieve
* cachefileset
* cachepath
* artifactproperty (since 2.0)
* artifactreport (since 2.0)
閱讀全文
摘要: cachefileset,為配置構(gòu)建一個(gè)有ivy緩存中的制品組成的ant fileset 從1.2版本起)。
這是一個(gè)后解析任務(wù)，有所有后解析任務(wù)共有的所有行為和屬性。注意這個(gè)任務(wù)不依賴retrieve，因?yàn)闃?gòu)建的fileset是由ivy緩存中的制品直接構(gòu)成的。
閱讀全文
摘要: ln命令用于連接文件或目錄,lndir命令用于創(chuàng)建目錄的符號(hào)鏈接，和ln不同的是lndir會(huì)自動(dòng)為源文件目錄下所有的文件和子目錄都建立對(duì)應(yīng)的符號(hào)鏈接.
閱讀全文
摘要: find命令用于查找文件和目錄，任何位于參數(shù)之前的字符串都將被視為欲查找的目錄。
find 可以指定查找條件如名稱，類型，時(shí)間，文件大小，權(quán)限和所有者查找，針對(duì)多個(gè)條件進(jìn)行與或非的邏輯運(yùn)算。我們可以控制find的查找的行為，還可以和其他命令組合使用。
閱讀全文
摘要: 為解析過的模塊配置構(gòu)建一個(gè)由在ivy 緩存(或者取決于useOrigin 設(shè)置的原始位置)中的制品組成的ant path.
閱讀全文
摘要: ls的用法: ls [OPTION]... [FILE]...
列舉文件信息(默認(rèn)當(dāng)前目錄), 如果-cftuvSUX或者--sort沒有設(shè)置則按照字典順序排序條目。
閱讀全文
摘要: 交付當(dāng)前模塊的解析好的描述符，而且可能執(zhí)行依賴的遞歸交付。
這個(gè)任務(wù)主要做兩個(gè)事情：
1. 生成一個(gè)解析好的ivy 文件
2. 執(zhí)行遞歸交付
閱讀全文
工作中發(fā)現(xiàn)的一個(gè)非常奇怪也很有趣事情，有關(guān)MANIFEST.MF文件中的分行和空格的格式要求，分享給大家。
對(duì)于通常的MANIFEST.MF文件，一般格式是：
Class-Path: lib/a.jar lib/b.jar lib/c.jar lib/d.jar lib/e.jar lib/f.jar
在一行之內(nèi)將所有的jar包路徑寫上，空格分隔即可。
但是對(duì)于一些大型的項(xiàng)目，因?yàn)橐蕾嚢姸啵热绱笥?0個(gè)，那么如果還寫在一行內(nèi)，就會(huì)出現(xiàn)一個(gè)長(zhǎng)度驚人的行。程序運(yùn)行倒不會(huì)有任何問題，但是對(duì)于版本控制就很不友好，如增加或者減少一個(gè)依賴包，這行就會(huì)被改寫。以后compare不同版本時(shí)，只能知道這行被修改了確無法直接知道是做了什么修改，必須通過其他方式才能對(duì)比出來。
同樣的問題發(fā)生在code merge時(shí)，如果兩個(gè)分支都修改了這個(gè)文件，就必須通過手工來進(jìn)行merge，而且要對(duì)照出來彼此到底改了什么，很困難而且容易出錯(cuò)。
因此一個(gè)改進(jìn)就是將這個(gè)文件中的依賴按照一行一個(gè)依賴的方式重寫，這樣以后修改時(shí)只會(huì)修改改依賴所在的行，很容易就對(duì)比出來具體做了哪些感動(dòng)，code merge時(shí)版本控制軟件一般也很容易直接自動(dòng)merge成功。
修改后的文件類似如下：
Class-Path: lib/a.jar
lib/b.jar
lib/c.jar
lib/d.jar
lib/e.jar
lib/f.jar
但是在實(shí)際操作時(shí)發(fā)生了意料之外的問題，會(huì)出現(xiàn)異常或者類無法找到，經(jīng)檢查發(fā)現(xiàn)問題出現(xiàn)在MANIFEST.MF的格式上，MANIFEST.MF對(duì)于分行和空格是有特殊要求的：
1. 每行的最后一個(gè)jar的名稱后不容許有空格
即" lib/b.jar"在b.jar后必須回車結(jié)束本行，不能有空格，一個(gè)都不能
2. 每行的開頭必須有不少于2個(gè)空格
即" lib/b.jar"在b.jar前必須有不下兩個(gè)空格
以上兩個(gè)條件有一個(gè)不滿足都會(huì)出現(xiàn)問題，有點(diǎn)古怪。
摘要: 發(fā)行當(dāng)前模塊的制品和已解析的描述符(已交付的ivy文件)。
這個(gè)任務(wù)的目的是發(fā)行當(dāng)前模塊描述符和它的聲明的發(fā)行制品到倉(cāng)庫(kù)中。
閱讀全文
摘要: configure任務(wù)用于通過xml設(shè)置文件來配置ivy。
閱讀全文
摘要: retrieve任務(wù)復(fù)制解析好的依賴到你的文件系統(tǒng)的任何位置。
這是一個(gè)post resolve任務(wù)，帶有所有post resolve任務(wù)共有的所有的行為和屬性。
閱讀全文
摘要: 解析任務(wù)實(shí)際解析在ivy文件中描述的依賴，并將解析后的依賴放置到ivy緩存中。
如果在resolve任務(wù)前沒有調(diào)用configure任務(wù)，則將使用默認(rèn)的configuration (等同于不帶參數(shù)的調(diào)用configure).
閱讀全文
摘要: buildlist任務(wù)用于獲取按照ivy依賴信息從小到大排序的文件(通常是build.xml文件) 列表，或者相反(從1.2之后)
這個(gè)任務(wù)在結(jié)合subant構(gòu)建相關(guān)項(xiàng)目集合時(shí)特別有效, 可以確保依賴在其他依賴它的模塊之前被構(gòu)建
閱讀全文
摘要: 轉(zhuǎn)一個(gè)blog，關(guān)于如何使用ivy來處理native的依賴，對(duì)于有使用JNI開發(fā)的朋友應(yīng)該很有價(jià)值。
原文blog地址：http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy/
閱讀全文
我們的團(tuán)隊(duì)一直埋怨說我們的代碼規(guī)模太大，結(jié)構(gòu)太復(fù)雜，維護(hù)難度大而成本高。
最明顯的一個(gè)弊病，就是在clearcase里面打開一個(gè)文件的version tree，密密麻麻，橫七豎八，我們戲稱為"蜘蛛網(wǎng)"。
然而昨天一位出差在外的同事，在維護(hù)公司另外一個(gè)產(chǎn)品的時(shí)候，有了驚喜發(fā)現(xiàn)：
我們的代碼規(guī)模比起來還是差得遠(yuǎn)！
有圖為證：
我的評(píng)價(jià)只有一個(gè)字：
暈!
PS:
解釋一下，有些朋友沒有用過版本控制軟件的version tree，可能不大明白。
這個(gè)是version tree，是一個(gè)文件(注意，只是一個(gè)文件)的版本和分支歷史，一般的版本控制軟件都會(huì)提供類似的視圖。
圖上藍(lán)色直線條的是這個(gè)文件的不同分支和這個(gè)這個(gè)分支下的不同版本，紅色的線條是code merge，就是從一個(gè)分支的某個(gè)版本merge 代碼到另外一個(gè)分支上時(shí)為了表示這種merge關(guān)系而增加一種表示方式。
從圖上看，這個(gè)文件的分支過百了，版本應(yīng)該過千，紅色的merge線在某些地方已經(jīng)要凝成實(shí)體了。這表明在這些版本之間有非常頻繁的code merge。
再補(bǔ)充一下：
這個(gè)圖片里面有些地方紅線密集程度有些不大對(duì)勁，某些分支幾乎每個(gè)版本修改都有被merge。正常開發(fā)中不應(yīng)該是這樣的，通常都只會(huì)是某個(gè)或某幾個(gè)版本被merge。
猜測(cè)出現(xiàn)這個(gè)情況的可能，有一種解釋就是可能在開發(fā)時(shí)使用了某些自動(dòng)merge的工具，當(dāng)該分支每出現(xiàn)一個(gè)新版本時(shí)就自動(dòng)merge到某個(gè)目標(biāo)分支，以保證兩個(gè)分支代碼的高度一致。當(dāng)然這個(gè)無法證實(shí)，只是我的一個(gè)猜測(cè)。
摘要: 這個(gè)是發(fā)生在上周周末的真實(shí)案例，因?yàn)閏xf client 端線程安全導(dǎo)致的錯(cuò)誤，總結(jié)出來希望其他使用cxf的朋友注意。
閱讀全文
摘要: ivy可以非常容易的作為一個(gè)單獨(dú)的程序使用。你所需要的只是一個(gè)java1.4+的運(yùn)行環(huán)境(JRE)!
閱讀全文
摘要: 使用ivy的主要和最頻繁的方式是在ant構(gòu)建文件中。不過，ivy也可以作為獨(dú)立的應(yīng)用被調(diào)用。
閱讀全文
摘要: ivy的使用完全是基于以"ivy文件"著稱的模塊描述符。ivy文件是xml文件，通常被稱為ivy.xml，包含模塊依賴的描述，它發(fā)布的制品和它的配置。
閱讀全文
摘要: 為了如您所想的工作，ivy有時(shí)需要一些設(shè)置。實(shí)際上，ivy可以在完全沒有任何特殊設(shè)置的情況下工作，查閱默認(rèn)設(shè)置文檔來獲取相關(guān)的更詳盡的信息。但是ivy有能力在完全不同的上下文下工作。你只需要正確的配置它。
閱讀全文
摘要: 安裝ivy主要有兩種方式，手工安裝或者自動(dòng)安裝。
閱讀全文
摘要: 這里有一些我們從我們的經(jīng)驗(yàn)和一些客戶的顧問工作中收集到的建議和最佳實(shí)踐。
5) 處理集成版本
6) 是否將依賴內(nèi)聯(lián)(inlining)
7) 雇用專家
閱讀全文
摘要: 這里有一些我們從我們的經(jīng)驗(yàn)和一些客戶的顧問工作中收集到的建議和最佳實(shí)踐。
1) 為所有的模塊添加模塊描述符
2) 使用自己的企業(yè)倉(cāng)庫(kù)
3) 至少在組織和模塊上使用模式
4) 為公共倉(cāng)庫(kù)發(fā)布ivysettings.xml
閱讀全文
摘要: 前面已經(jīng)介紹了ivy主要的術(shù)語和概念，現(xiàn)在是時(shí)候說明ivy如何工作的了。
閱讀全文
摘要: 在學(xué)習(xí)ivy的過程中陸陸續(xù)續(xù)的翻譯了一些ivy的參考文檔，現(xiàn)在準(zhǔn)備將這個(gè)工作進(jìn)行到底，將官方網(wǎng)站上完整的ivy參考文檔翻譯成中文。上面內(nèi)容是參考文檔的目錄，翻譯完成的部分我會(huì)陸續(xù)更新為中文并加入鏈接。
英文文檔地址請(qǐng)見：http://ant.apache.org/ivy/history/latest-milestone/reference.html
水平有限，出現(xiàn)錯(cuò)誤的地址請(qǐng)多多指正。
閱讀全文
摘要: ivy中引入了一些自己的概念，了解并理會(huì)這些概念對(duì)ivy的學(xué)習(xí)使用是有幫助的。這里翻譯一下官網(wǎng)的介紹ivy主要概念的文章，原文在此：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因內(nèi)容太長(zhǎng)而拆分，下面是第二部分。
閱讀全文
摘要: 日前升級(jí)內(nèi)存容量到8g之后，發(fā)現(xiàn)在xp下因?yàn)闊o法全部利用造成浪費(fèi)，因此考慮安裝ramdisk以充分利用資源。
閱讀全文
摘要: ivy中引入了一些自己的概念，了解并理會(huì)這些概念對(duì)ivy的學(xué)習(xí)使用是有幫助的。這里翻譯一下官網(wǎng)的介紹ivy主要概念的文章，原文在此：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因內(nèi)容太長(zhǎng)而拆分，下面是第一部分
閱讀全文
在ubuntu 8.10下安裝的svn，在將Ubuntu的語言修改為英文之后，出現(xiàn)錯(cuò)誤警告：
$ svn
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
Type 'svn help' for usage.
解決方法很簡(jiǎn)單，修改/etc/profile：
sudo vi /etc/profile
加入一行：
export LC_ALL=C
source /etc/profile
svn就可以正常工作了。
摘要: 安裝ubuntu 8.10時(shí)選擇的語言是中文，結(jié)果發(fā)現(xiàn)在命令行下執(zhí)行命令時(shí)，無法正確的顯示中文。
雖然我的英文不怎么樣，但是相比還不至于對(duì)付不了這種情況，還是改為使用英文好了。
google一下，非常簡(jiǎn)單，記錄下來避免日后遺忘
閱讀全文
摘要: 一直用vmvare跑linux作為開發(fā)測(cè)試平臺(tái)，但是總是在安裝vmvare tools時(shí)遇到問題，懶得再為此浪費(fèi)時(shí)間。
自己動(dòng)手，豐衣足食，手工安裝吧，
這個(gè)應(yīng)該是任何情況下都可以搞的定的方法。
閱讀全文
摘要: ivy中有一套自己特定的術(shù)語，了解并熟悉他們對(duì)ivy的使用非常重要，尤其對(duì)于ivy新手。
閱讀全文
摘要: 單位一臺(tái)服務(wù)器裝了SUSE 企業(yè)版 10，用PUTTY登錄不上去，用SSH Shell卻能登錄上去。
閱讀全文
摘要: 不想用apt直接裝，跑去sun的網(wǎng)站拖了一個(gè)jdk6 update13來.
閱讀全文
摘要: 今天在研究couchdb時(shí)偶然發(fā)現(xiàn)的一個(gè)blog，列舉了當(dāng)前比較不錯(cuò)的分布式 key-value存儲(chǔ)，并做了很有參考價(jià)值的分析，回帖也很有價(jià)值。
推薦對(duì)分布式存儲(chǔ)有興趣的朋友閱讀， 地址 http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
閱讀全文
從ivy的官網(wǎng)看到，ivy 2.1.0-rc1在3月30號(hào)發(fā)布，從名字可以看到這是一個(gè)候選發(fā)布/CR版本。
簡(jiǎn)單看一下新版本的主要特性：
1. maven2 能力增強(qiáng)，修訂了一些bug，覆蓋更多的pom特性
2. 更多的用于Ivy ant task和命令行的選項(xiàng)
3. 大量的bug修訂，文件在Jira和release文件中
官方的意見是鼓勵(lì)所有用戶升級(jí)到這個(gè)新版本。
在這里可以下載：
http://ant.apache.org/ivy/download.cgi
查了一下上一個(gè)大的release版本是2.0.0，在今年1月20號(hào)發(fā)布，迄今不到3個(gè)月，更新的速度
還是很不錯(cuò)的。沒有增加新的功能或者特殊的特性，主要還是在改善和maven2的集成以及bug
fix。
最近比較關(guān)注ivy這個(gè)小東西，希望能在maven之外多一些選擇，ivy目前的感覺不錯(cuò)。
剛得到的消息，實(shí)驗(yàn)了一下可以申請(qǐng)成功，有興趣的兄弟趕緊。
新聞出處：
http://www.javaeye.com/news/6754-officially-announced-google-app-engine-to-support-java
由于javaeye申明不容許轉(zhuǎn)載，所以我只能貼出來地址，詳情請(qǐng)自己過去看。
簡(jiǎn)單點(diǎn)說：
1. Google App Engine正式宣布支持Java！
2. Google App Engine 提供1萬個(gè)名額給感興趣的Java開發(fā)者試用，趕緊注冊(cè)：http://appengine.google.com/promo/java_runtime
再簡(jiǎn)單介紹一下申請(qǐng)流程：
1. 登錄google賬號(hào)，沒有的先申請(qǐng)
2. 有一個(gè)短信認(rèn)證的要求，填入自己的手機(jī)號(hào)碼，比如"+8613900000000"，短信很快的，一般10秒就能下來。
3. 申請(qǐng)app的頁(yè)面，注意先別急著填application的id和tilte，先看上面，有一行簡(jiǎn)單的提說說要不要試試java版本的GAE，點(diǎn)進(jìn)去
4. 這里有一個(gè)sing up的按鈕，點(diǎn)吧，這個(gè)才是真正的申請(qǐng)java版本GAE的地方
5. 成功后會(huì)告之收到申請(qǐng)，如何如何。等一會(huì)去看gmail，如果成功就會(huì)收到一封郵件說account actived。大概3-5分鐘吧。
6. 再去申請(qǐng)app吧，慢慢來
摘要: maven很強(qiáng)大，但是遠(yuǎn)不完美，令人煩惱的地方也不少。看到Ivy似乎日漸成熟，試試看這個(gè)小東西表現(xiàn)如何，畢竟后面有那個(gè)強(qiáng)大的我喜歡的ant。
折騰了一番，整理出來點(diǎn)東西，分享給對(duì)ivy同樣感興趣的朋友。依然是"初學(xué)"系列，提供給新手入門使用。
閱讀全文
摘要: 從http://m2eclipse.sonatype.org/update下在線安裝m2eclipse，現(xiàn)在的版本是0.9.7，20090209的版本，應(yīng)該是新出來的。安裝時(shí)出現(xiàn)錯(cuò)誤提示導(dǎo)致無法安裝：
Cannot complete the request. See the details.
Cannot find a solution satisfying the following requirements org.eclipse.ui.workbench [3.4.2.M20090127-1700].
閱讀全文
摘要: 升級(jí)到m2eclipse 0.9.7版本后，發(fā)現(xiàn)一個(gè)問題，maven Assembly plugin無法工作，具體是在eclipse下執(zhí)行"run as" --> "maven package"時(shí)，報(bào)錯(cuò)：
[INFO] Failed to create assembly: Error adding file 'net.runafter.nptt:NpttCore:jar:0.1.0' to archive:
G:\workspace\private\tools\nptt\trunk\NpttCore\target\classes isn't a file.
可以看到，maven Assembly plugin試圖以操作文件的方式操作目錄NpttCore\target\classes，因此失敗造成整個(gè)package命令執(zhí)行失敗。
閱讀全文
摘要: 折騰了好久，終于搞定subversive和svn connector的安裝了，過程很痛苦，因?yàn)閑clipse的在線安裝實(shí)在是太慢了......
最后我的總結(jié)就是不要直接從網(wǎng)上安裝，太慢太慢，會(huì)吐血而亡的，我已經(jīng)深刻領(lǐng)略了......
正確的方法是先從官方網(wǎng)站上下載安裝包，然后再用eclipse的software update工具安裝，這樣速度就很快。我的1m的adsl，如果直接網(wǎng)上安裝，大概1k下載速度，直接http下載安裝包，大概在50-100k之間，差別夠大吧？
閱讀全文
摘要: 總結(jié)，建議在使用eclipse安裝插件時(shí)，先在Manager Sites中取消其他所有站點(diǎn)！
閱讀全文
摘要: subversion默認(rèn)的diff工具比較簡(jiǎn)單，文本界面，在使用時(shí)不是很理想。
winmerge則是一款非常優(yōu)秀的diff/merger工具，由于winmerge自帶和clearcase的集成功能，因此我在公司工作環(huán)境下一直都是使用winmerge替代clearcase自帶的diff工具使用了。
近日使用svn，每次執(zhí)行svn diff后都對(duì)出來的文本比較結(jié)果的效果不滿意，即使換成TortoiseSVN的diff工具也還是不夠好。因此產(chǎn)生想法，能否將winmerger集成到subversion.
google了一下"winmerge subversion"，順利在國(guó)外的一個(gè)blog上找到答案，實(shí)驗(yàn)了一下，很成功，效果非常好，現(xiàn)在將具體方法共享出來。
閱讀全文
摘要: 家里的服務(wù)器使用的是subversion1.4的版本，最近發(fā)現(xiàn)1.5已經(jīng)陸續(xù)出現(xiàn)了多個(gè)bugfix的小版本更新，考慮到1.5出來時(shí)間也比較長(zhǎng)了，應(yīng)該已經(jīng)穩(wěn)定下來。而且1.5也帶來了不少新特性，聽聞速度也有所提升，因此考慮升級(jí)到最新版本1.5.5。
閱讀全文
摘要: 近期由于公司有意向在未來將目前的一個(gè)大型產(chǎn)品從weblogic移植到glassfish，因此提前學(xué)習(xí)glassfish以做好準(zhǔn)備。
首先從下載安裝開發(fā)，學(xué)習(xí)如何搭建glassfish的開發(fā)環(huán)境。
閱讀全文
摘要: 在上一篇文章中，討論到在對(duì)maven的機(jī)制不熟悉的情況下，為了實(shí)現(xiàn)自己需要的打包格式而使用maven ant task以maven + ant的方式來實(shí)現(xiàn)非標(biāo)準(zhǔn)打包，而現(xiàn)在要介紹的是maven中針對(duì)打包任務(wù)而提供的標(biāo)準(zhǔn)插件：assembly plugin。
閱讀全文
摘要: maven很強(qiáng)大，但是總有些事情干起來不是得心應(yīng)手，沒有使用ant時(shí)那種想怎么干就怎么干的流暢感。尤其當(dāng)要打包一個(gè)特殊（相對(duì)maven的標(biāo)準(zhǔn)架構(gòu)而且）時(shí)，常有不知所措的感覺。當(dāng)然這個(gè)應(yīng)該和自己對(duì)maven的了解不夠有關(guān)，畢竟，“初學(xué)maven”嘛。
但是maven在依賴管理方面實(shí)在是太強(qiáng)大了，太喜歡，退回原來的ant方式完全不可能，我想用過maven的人，一般是不會(huì)有回到原來在 cvs,subversion中checkin/checkout n個(gè)jar包的時(shí)代，僅此一項(xiàng)理由就足夠繼續(xù)堅(jiān)持使用maven了。
然而ant的靈活又難于忘懷，尤其是從ant的build.xml一路走來的人，總是回不知不覺間想到ant的美好。魚與熊掌，我都想要。
閱讀全文
摘要: 一些看到過的java資源，包括項(xiàng)目，工具等，因?yàn)闀簳r(shí)沒有時(shí)間仔細(xì)研究或者暫時(shí)沒有用到，但是希望能保留這些信息以便在需要時(shí)方便找到。
純屬個(gè)人收藏。
閱讀全文
摘要: 一些看到過的java資源，包括項(xiàng)目，工具等，因?yàn)闀簳r(shí)沒有時(shí)間仔細(xì)研究或者暫時(shí)沒有用到，但是希望能保留這些信息以便在需要時(shí)方便找到。
純屬個(gè)人收藏，基本是作為記事本使用。
閱讀全文
摘要: 之前看到過一些Nexus的介紹，由于剛開始接觸maven時(shí)使用的私服是artifactory，因此沒有太在意。今天想著既然Nexus能有膽量出來混，應(yīng)該有點(diǎn)真本事才是，看了一下nexus的安裝介紹，挺簡(jiǎn)單的，試試無妨。因此裝上小試了一下，結(jié)果喜出望外，nexus的表現(xiàn)非常不錯(cuò)，尤其是在開啟遠(yuǎn)程索引之后，簡(jiǎn)直太方便了。
于是決定放棄artifactory改而使用nexus作為自己的maven私服。恩，慚愧，頗有點(diǎn)喜新厭舊的味道，artifactory才裝上來沒有幾天，就慘遭拋棄......
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內(nèi)容太長(zhǎng)拆開，本文是5.10-5.14，主要話題是Rerunning failed tests,JUnit tests,JDK 1.4,Running TestNG programmatically和BeanShell and advanced group selection。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內(nèi)容太長(zhǎng)拆開，本文是5.8-5.9，主要話題是Class level annotations和Parallel running and time-outs。
閱讀全文
摘要: 這篇文章展示一個(gè)解決方案，用來解決企業(yè)應(yīng)用中的可伸縮性問題,這些應(yīng)用必須支持即要求快速響應(yīng)而又長(zhǎng)時(shí)間運(yùn)行的業(yè)務(wù)程序......
翻譯自theserverside.com的一篇文章，原文地址請(qǐng)見http://www.theserverside.com/tt/articles/article.tss?l=IOandSEDAModel。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內(nèi)容太長(zhǎng)拆開，本文是5.6-5.7，主要話題是Dependent methods和Factories
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內(nèi)容太長(zhǎng)拆開，本文是5.5，主要話題是Parameters
閱讀全文
摘要: 在eclipse 3.4 Ganymede 中安裝subversion插件遇到的怪事，和最后的解決方法，包括subclipse和subversive的安裝。
如果在eclipse 3.4 Ganymede 中安裝subversion插件沒有遇到問題的，請(qǐng)無視本帖。
閱讀全文
摘要: 前段時(shí)間研究過一下maven，中途因?yàn)楣ぷ髅R置了一段時(shí)間，重新再看時(shí)發(fā)現(xiàn)安裝過程基本忘光。只好找資料看然后再來一遍，將 maven，artifactory和m2eclipse安裝使用的全過程記錄整理出來，備忘。另外我想這些資料應(yīng)該比較適合maven的入門新手，照做一遍就可以完成三個(gè)東西的安裝設(shè)置，然后就可以學(xué)習(xí)和使用了。
閱讀全文
摘要: 在eclipse中使用subclipse，發(fā)現(xiàn)無法訪問到目標(biāo)subversion服務(wù)器，總是報(bào)服務(wù)器無法連接。我連的subversion服務(wù)器采用apache以http的形式發(fā)布，用瀏覽器直接打開URL可以訪問。由于公司網(wǎng)絡(luò)環(huán)境是要求使用http proxy的，因此第一個(gè)想法就是eclipse沒有使用http proxy因此無法連接外網(wǎng)。
最后才發(fā)現(xiàn)，subversion客戶端訪問外網(wǎng)時(shí)，http proxy的設(shè)置是通過“%APPDATA%\Subversion\servers”這里來設(shè)置的，eclipse的設(shè)置對(duì)它無效。
閱讀全文
摘要: 初學(xué)guice，每每看到guice 綁定常量的用法介紹，總是在想這個(gè)功能有什么用處？實(shí)在想不出來用它的場(chǎng)合和優(yōu)點(diǎn)，感覺頗為雞肋。
今天閑坐家中，又無聊翻書打發(fā)時(shí)間，再次看到這個(gè)東東，作者和我似乎有相同的想法，不過他的一句“既然我們可以使用自定義注解，那么這里也可以替換成@Named，這里不再贅述。”，讓我突發(fā)奇想，能不能這樣用呢？
閱讀全文
摘要: 問題終于找到，簡(jiǎn)單的說是因?yàn)閖ava 系列化的效率低下，而ejb調(diào)用之間又大量使用系列化，因此造成極大的性能消耗，而且也影響到響應(yīng)時(shí)間。仔細(xì)分析了一下項(xiàng)目情況，呵呵，情況非常嚴(yán)重，系統(tǒng)架構(gòu)是按照三層來設(shè)計(jì)的，每個(gè)層都是ejb，調(diào)下一層都是通過遠(yuǎn)程接口，而且層之間可能還多個(gè)ejb的調(diào)用。
總結(jié)一下：
1. java serialize 非常慢
2. enable-call-by-reference可以有效避免這個(gè)開銷
因此，能enable-call-by-reference就盡量enable-call-by-reference。
閱讀全文
摘要: 接上篇，有興趣的朋友可以直接拿我的測(cè)試代碼自行測(cè)試,請(qǐng)自行修改諸如線程數(shù)，執(zhí)行時(shí)間，系列化的數(shù)據(jù)量大小等參數(shù)。如果想嘗試做thread dump，可以打開相關(guān)的兩個(gè)注釋，會(huì)更方便一些，代碼中都有相應(yīng)的注釋可供參考。
閱讀全文
摘要: 這是加入新公司后接手的第一個(gè)項(xiàng)目，使用weblogic9.2 + ejb2.0，壓力測(cè)試時(shí)發(fā)現(xiàn)速度非常慢，響應(yīng)時(shí)間很不理想，檢查日志發(fā)現(xiàn)，某些ejb相互調(diào)用時(shí)方法調(diào)用的時(shí)間非常長(zhǎng)，高達(dá)300-500毫秒。非常夸張，因?yàn)閮蓚€(gè)日志之間只是間隔了一個(gè)ejb調(diào)用。通過thread dump分析后發(fā)現(xiàn)有相當(dāng)多的線程在wait，檢查線程調(diào)用綻發(fā)現(xiàn)是在將參數(shù)進(jìn)行序列化時(shí)，線程試圖加鎖但是鎖被占用，因此處于等待狀態(tài)。考慮到 thread dump的這一瞬間，有多達(dá)30-50個(gè)線程都在同時(shí)試圖在同一個(gè)鎖上加鎖，很明顯這里的鎖競(jìng)爭(zhēng)非常嚴(yán)重。
因此強(qiáng)烈懷疑是java的序列化機(jī)制導(dǎo)致的問題。
閱讀全文
摘要: 修改兩個(gè)resin的httpd.sh腳本，加入對(duì)JAVA_HOME的不同設(shè)置就可以了搞定這個(gè)問題，呵呵，最后的方法還是蠻簡(jiǎn)單的。
閱讀全文
摘要: 初學(xué)maven，遇到不少問題，記錄下來，呵呵，依然是備忘兼共享。
閱讀全文
摘要: 操作系統(tǒng)安裝完畢后，開始設(shè)置apt，使用apt來安裝基本軟件和java開發(fā)工具。
閱讀全文
摘要: Ubuntu JeOS是推出一個(gè)針對(duì)虛擬技術(shù)應(yīng)用的全新版本，簡(jiǎn)單的說就是在從Ubuntu操作系統(tǒng)中去除了幾個(gè)虛擬系統(tǒng)不需要的軟件包，為虛擬化目的改進(jìn)操作系統(tǒng)后制造出的軟件。
可以從verycd上載最新的ubuntu 7.10 jeos版本，地址http://www.verycd.com/topics/208424/，150m而已。
我的目標(biāo)是，將Ubuntu JeOS改造為可以運(yùn)行java程序，當(dāng)然一些必要的應(yīng)用軟件需要安裝上去。然后在vmware中輕松的啟動(dòng)多個(gè)Ubuntu JeOS，以方便對(duì)一些需要多機(jī)分布的程序進(jìn)行測(cè)試。
閱讀全文
摘要: 近日因故離職，原來在公司開發(fā)機(jī)上安裝的svn不能再用了，只好在自己家里的電腦上再搭建一套svn環(huán)境。操作系統(tǒng)采用windows server 2003，安裝配置比較簡(jiǎn)單，基本按照下面的步驟一步一步來就可以，簡(jiǎn)單記錄下來備忘。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第5章，由于內(nèi)容太長(zhǎng)拆開，本文是5.1-5.4，主要話題是test group，
原文請(qǐng)見 http://testng.org/doc/documentation-main.html
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第4章，原文請(qǐng)見 http://testng.org/doc/documentation-main.html
閱讀全文
摘要: 在TestNG的官網(wǎng)上看到他們?cè)谕扑]這本電子書，TestNG的作者出的，Hani Suleiman 和 Cedric Beust的“新一代Java測(cè)試: TestNG和高階理念”, TestNG至今唯一的一本電子書，好不容易從電驢上下載下來的，分享給其他TestNG的愛好者。
推薦所有TestNG愛好者，尤其是新手。
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第3章，原文請(qǐng)見 http://testng.org/doc/documentation-main.html
閱讀全文
摘要: TestNG的官方文檔的中文翻譯版第二章，原文請(qǐng)見 http://testng.org/doc/documentation-main.html
閱讀全文
摘要: 從infoQ官網(wǎng)看到的一個(gè)文章，“設(shè)計(jì)和代碼審查：是好、是壞還是不堪入目？”，深有感觸，談?wù)勛约旱囊恍┯H身經(jīng)歷，發(fā)發(fā)牢騷吧。
原文在http://www.infoq.com/cn/news/2008/03/code-review-antipatterns，建議先看原文。
作者在文章開頭提到，“復(fù)查的承諾是改進(jìn)軟件質(zhì)量、確保與標(biāo)準(zhǔn)的一致性，并且可以作為一種有價(jià)值的工具為開發(fā)人員服務(wù)，但是它們的執(zhí)行方式卻影響到了自身的價(jià)值。在某些組織中，它們可能真的見效；而在另一些地方，可能也不過是官僚作風(fēng)的一種體現(xiàn)而已。”
最近我們部門也在進(jìn)行代碼審查，去年年底做過一次，現(xiàn)在還在做。可是，我很遺憾的發(fā)現(xiàn)，我們的工作是更多的是驗(yàn)證了上面的擔(dān)憂，“不過是官僚作風(fēng)的一種體現(xiàn)”。
閱讀全文
摘要: 最近決定開始使用TestNG來替代junit，作為未來的單元測(cè)試基礎(chǔ)組件。
google了一下沒有找到好的詳細(xì)的文檔，最后發(fā)現(xiàn)官網(wǎng)上的文檔其實(shí)挺全的，決定翻譯一下。
TestNG的官方文檔請(qǐng)見： http://testng.org/doc/documentation-main.html
閱讀全文
摘要: google到的一份詳細(xì)的netstat資料,可惜是英文版本,先保存下來慢慢細(xì)看,有時(shí)間再翻譯出一個(gè)中文版本來.
原文地址: http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/linux/netstat.8.html
閱讀全文
摘要: 近日發(fā)現(xiàn)寫的一個(gè)java程序的數(shù)據(jù)庫(kù)連接在大壓力下工作不打正常,因此研究了一下dbcp,中間為了查看mysql服務(wù)器的數(shù)據(jù)庫(kù)連接情況,需要使用 netstat來查看端口和連接, 將使用到的命令整理了一下備忘, 這些命令同樣可以用于查看其他運(yùn)用程序的端口和連接情況.
閱讀全文
摘要: mysql 4.1的linux安裝配置過程，整理出來備忘
閱讀全文
摘要: dbcp配置中文版本，翻譯自apache 官方文檔，原文請(qǐng)見http://commons.apache.org/dbcp/configuration.html。
閱讀全文
摘要: 使用loadrunner的java Vuser時(shí)，發(fā)現(xiàn)出現(xiàn)了沒有License的情況，經(jīng)過一番折騰，發(fā)現(xiàn)是自己的設(shè)置不對(duì)，google了一下發(fā)現(xiàn)很多人似乎犯了和我類似的錯(cuò)誤，整理一下分享出來，避免后來人繼續(xù)犯錯(cuò)。
閱讀全文
摘要: 最近準(zhǔn)備開工一個(gè)大項(xiàng)目，給自己練手用，考慮需要保存源代碼，又不方便放到公司的cvs上。因此決定安裝一個(gè)給自己用，順便學(xué)習(xí)一下 subversion。簡(jiǎn)單翻了一下資料，決定使用apache + subversion的方式，比較適合我，而且這種方式的好處是可以用瀏覽器就直接訪問，方便瀏覽。
整理了一下安裝配置過程，給新手一個(gè)簡(jiǎn)單可行的參考。
閱讀全文
摘要: 依賴注入對(duì)設(shè)計(jì)有利，而spring則促進(jìn)了依賴注入的使用。
代碼維護(hù)是需要成本的，寫出易于維護(hù)的代碼，是一個(gè)優(yōu)秀程序員的基本素養(yǎng)。
閱讀全文
摘要: jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一個(gè)顯示當(dāng)前所有java進(jìn)程pid的命令，簡(jiǎn)單實(shí)用，非常適合在linux/unix平臺(tái)上簡(jiǎn)單察看當(dāng)前java進(jìn)程的一些簡(jiǎn)單情況。
閱讀全文
摘要: 從對(duì)resin源碼的追蹤到resin配置文件中的設(shè)置，可以明確的看到，resin在設(shè)計(jì)上是提供了session id 的reuse功能，而且resin.conf默認(rèn)就是打開reuse的。慚愧的是，我一直不知道......
閱讀全文
摘要: 上文中詳細(xì)描述了問題的表現(xiàn)情況，由于這個(gè)特性嚴(yán)重影響到目前為公司設(shè)計(jì)的一套前臺(tái)統(tǒng)一認(rèn)證方案，因此不得不特別關(guān)注。好在resin的源代碼是公開的，直接從resin的官網(wǎng)將resin的源代碼拿下來，看resin到底是如何處理的。
閱讀全文
摘要: 看到有留言，對(duì)我如此“執(zhí)著”的關(guān)注session創(chuàng)建很好奇，解釋一下吧。
首先是關(guān)注性能，前面提到過session的使用是有代價(jià)的，需要在保存在服務(wù)器端內(nèi)容中，每次request.getSeesion()方法獲取 session時(shí)，實(shí)際是在服務(wù)器段的一個(gè)大的hasp結(jié)構(gòu)中以當(dāng)前的jsessionid為key，獲取對(duì)應(yīng)的value HttpSession對(duì)象，這個(gè)過程是需要消耗cpu的，當(dāng)然目前hash算法比較好，這里消耗不那么明顯。而一般的應(yīng)用，消耗的cpu遠(yuǎn)比這個(gè)小開銷大出2-3個(gè)數(shù)量級(jí)，因此通常情況不敏感。如果這個(gè)session是我們需要使用的，那么付出這些內(nèi)存和cpu的代碼是完全值得的。但是，如果產(chǎn)生大量的沒有任何用處的"垃圾session"，對(duì)大容量，大并發(fā)，需要長(zhǎng)期穩(wěn)定運(yùn)行的系統(tǒng)會(huì)帶來很無謂的負(fù)載。
閱讀全文
摘要: 按照前面的方法，將jsp頁(yè)面加入<%@ page session="false"%>之后，發(fā)現(xiàn)還是有新的session會(huì)意外的蹦出來。仔細(xì)檢查action沒有操作session，那這次是誰干的呢？將目光轉(zhuǎn)回jsp文件，首先來次狠的，將這個(gè)jsp文件的內(nèi)容刪空為只有純html內(nèi)容。重新運(yùn)行后發(fā)現(xiàn)不會(huì)自動(dòng)生成session，ok，問題在jsp文件里面了。將原來的內(nèi)容一點(diǎn)點(diǎn)的加回去，反復(fù)測(cè)試直到session自動(dòng)創(chuàng)建的問題再次出現(xiàn), 哈,發(fā)現(xiàn)問題出現(xiàn)在webwork的標(biāo)簽上。
閱讀全文
摘要: jsp文件是session創(chuàng)建的一個(gè)源頭，這里指的不是在jsp文件中用代碼或者標(biāo)簽來操作session，這些都是在控制中的。容易忽視或者說根本就不會(huì)意識(shí)到的（比如我，就是寫jsp三年后才發(fā)現(xiàn)的)是，jsp有自動(dòng)創(chuàng)建session的機(jī)制，在jsp頁(yè)面中，如果沒有明確的給出 <% @page session="false"%>，jsp頁(yè)面會(huì)非常乖巧（如果剛好需要）或者說是偷偷摸摸（如果不需要）的自動(dòng)在生成的java文件中增加一句： javax.servlet.http.HttpSession session = request.getSession(true)。
閱讀全文
摘要: 在HttpServlet中，HttpSession對(duì)象通常在request.getSession(true)方法調(diào)用時(shí)才創(chuàng)建。 HttpSession的使用是有代價(jià)的，需要占用服務(wù)器資源，本著能不浪費(fèi)就不浪費(fèi)的原則，我希望系統(tǒng)中的session都在掌握之中，在需要?jiǎng)?chuàng)建時(shí)由我們的代碼明確創(chuàng)建。但是最近在開發(fā)中發(fā)現(xiàn)，新的session對(duì)象經(jīng)常在意料之外出現(xiàn)，究竟是誰在創(chuàng)建session呢？
閱讀全文
摘要: 近期因工作需求探索apache + resin的多機(jī)負(fù)載分布和多個(gè)webapp統(tǒng)一認(rèn)證的實(shí)現(xiàn)方案, 期間設(shè)計(jì)多個(gè)webapp統(tǒng)一認(rèn)證的實(shí)現(xiàn)方案時(shí), 發(fā)現(xiàn)resin下通過cookie來傳遞jsessionid和通過url重寫將jsessionid放url中傳遞, 會(huì)有細(xì)微的差異.
注：后來研究發(fā)現(xiàn)是resin提供的session id reuse特性，只是此文第一次發(fā)布時(shí)我還不知道有此特性，慚愧。
閱讀全文
摘要: 發(fā)生在我身上的實(shí)際故事，最后發(fā)現(xiàn)和axis解析xml時(shí)的處理機(jī)制有關(guān)，namespace的有無會(huì)影響xml解析的方式，簡(jiǎn)單的說就是有namespace時(shí)按照元素名解析，沒有namespace則按照index下標(biāo)的順序來解析。
閱讀全文
摘要: 在網(wǎng)上找了一些apache下安裝mod_rewrite模塊的文章，說得都很輕巧，但是俺一路碰壁，怎么都出不來。整理了一下，以后再來研究。
閱讀全文
摘要: 前段時(shí)間做公司前臺(tái)方案的技術(shù)探索時(shí)，涉及到j(luò)sseionid的傳遞，期間嘗試使用resin自己的url rewrite功能來傳遞jsessionid參數(shù)，總結(jié)如下
閱讀全文
摘要: 前段時(shí)間，對(duì)公司前臺(tái)多機(jī)分布方案的做了一些探索，總結(jié)了一些東西，貼出來分享。apache + resin的多機(jī)部署，類似內(nèi)容網(wǎng)上比較多，但是都不夠詳細(xì)，我第一次弄時(shí)費(fèi)力不少，希望后來人可以更方便一些。
閱讀全文
摘要: 首先把問題擺出來，看這個(gè)代碼段
String a = "ab";
String b = "a" + "b";
System.out.println((a == b));
打印結(jié)果會(huì)是什么？true or false ?
閱讀全文
摘要: RESIN下驗(yàn)證碼無法顯示的問題，驗(yàn)證碼的代碼就是google上查找到的最常見的代碼，服務(wù)器采用resin部署于linux或unix。不是常見的out.clear()問題，這次的問題發(fā)現(xiàn)在一個(gè)我壓根就沒有想到的地方，profile DISPLAY 環(huán)境變量。
閱讀全文
摘要: 摘要:讀書筆記，中文名"版本控制之道-使用cvs"。介紹cvs命令checkout,commit,update
閱讀全文
摘要: 讀書筆記，中文名"版本控制之道-使用cvs"。介紹cvs命令status,annotate,log,diff。
閱讀全文
摘要: 讀書筆記，中文名"版本控制之道-使用cvs"。介紹cvs命令import,add,release,remove
閱讀全文
摘要: 讀書筆記，中文名"版本控制之道-使用cvs"，英文名"Pragmatic Version Control-Using CVS"。
閱讀全文