2010年5月5日
#
摘要: 之前遇到幾次現(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è)頁面都被重定向到新地址，然后新地址再次被重定向。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頁面時(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倉庫。隨后發(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上的頁面目前還沒有放出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ù)庫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庫的企業(yè)級(jí)搜索服務(wù)器，本文記錄了solr的安裝過程，版本為最新的1.4.1。
閱讀全文
摘要: Tokyo Tyrant是目前評(píng)價(jià)最高的key-value數(shù)據(jù)庫之一，本文記錄在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.aygfsteel.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的程序員也是程序員啊！
閱讀全文