摘要: 說說遺憾：
1、OSGi在B/S架構中還不好應用。雖然例子是B/S的，可是居然是Servlet模型，里面解釋了目前Equinox項目也在擴展應用服務器支持和JSP支持等，可是起碼目前還不成熟。
2、模塊的粒度很成問題。目前OSGi的契約機制與java interface機制對比一下。OSGi不可能完全取代本地的interface式的解藕，當然人家也沒這么說。只使我擔心過渡設計后，過細的Bundle肯定會得不償失，所以需要有人設計/計劃這個粒度。這個可能與基于Web services的SOA架構面臨類似的問題，需要好的架構師。
3、文檔不友好么？說實話，很感謝BlueDavy和OSGi觀察者那些大牛的貢獻。但是感覺production的樣例工程還是很難搞到（其實Eclipse plugins的例子滿多哈，可惜沒啥文檔，需要硬著頭皮看），對應的指導文檔還沒出現。BlueDavy提供的servlet實現我們不可能跟上，畢竟簡單也是一種需求。（那誰說過度設計比設計不足更可怕，那個我不是唱反調，我希望我們都能找到那個sweet point，有個好的參照那最好不過了）。 <  閱讀全文

     摘要: 先分析一下在輕量化的Java EE下面他們存在的意義：
1、有的人說過在Web項目中Manager和DAO是同意的，尤其是在透明ORM存在下，DAO由于往往是CRUD的實現場所，而Manager卻往往是薄薄的一層門面，很多人就在質疑兩者的合并問題。可是robbin曾經進行過一個精辟的分析，雖然兩者做的看起來差不多，可是兩者的事務屬性卻不一樣，Manager應該有清晰的事務界限，而DAO不應關心于此。也就是說Manager可能會將幾個DAO方法組合調用，然后封裝在一個事物中。這樣說明確了兩者的一個重要區別，我們也能體會在使用聲明事務的時候有一個分明的事務界限是很有意義的，否則就有可能把Manager中的一個事物拆分，這樣實際上就錯誤了。
2、有些人質疑透明ORM存在的情況下DAO存在的意義，因為透明ORM基本已經隔離了不同數據庫的方言區別。這個也很簡單，Rod大叔分析過。透明ORM存在的情況下DAO起到了隔離透明ORM與EJB或者JDBC實現的作用，這幾種實現實際上是應該考慮到的。
3、還有一個問題，就是DAO是否應該隱藏透明ORM的API。因為前面說到了DAO起  閱讀全文

     摘要: 在Eclipse里面運行functional-test這個target的時候發現報錯（test target葉出錯的）：
Could not create task or type of type: junit.
我就想當然的把junit-3.8.1.jar拷貝到我的%ANT_HOME%/lib下面了，結果問題依舊。
......
解決方法目前看最好的就是在Eclipse的Window->Preferences->Ant->Runtime->Classpath里面Ant_Home你指定一下就可以了，可以是你自己的Ant或者Eclipse/plugins里面的ant，這沒關系，然后它就會自動掃描相應/lib目錄了（之前你應該已經把junit-3.8.1.jar拷貝過去了）。
然后就搞定了。注意，只有在Eclipse運行Ant才有可能遇上這個問題:D
  閱讀全文

     摘要: 今天先看看Springside的bookstore的domain設計，這不是springside的重點，先看看。
從hbm看起，在springside-bookstore/src/org.springside.bookstore.commons.domain.hbm下面放著這些hbm。
在Order.hbm.xml里面可以看到一個list映射。list映射可以按照順序持久化one-to-many關系。使用了映射后OrderItem就沒有單獨的class聲明了，完全以一種組件的形式被映射到Order里面。  閱讀全文

     摘要: 1、Java從語言轉向平臺。如同.Net，JVM本身提供了平臺的抽象。將會擴展動態語言與腳本語言的支持。
2、企業應用的開發過程將簡化，如MDD一類，但目的是集中精力開發商業邏輯，而不是純簡化代碼或者什么什么。小型應用可能會轉向動態語言或腳本語言所營造的舒適開發框架，如RoR，或其它Rails。
3、富領域模型替代貧血模型，基于JPA。
4、目前的AOP、IoC工具依然會流行，而不一定會限定于EJB3模型中。事實說了算，Spring這種事實性標準影響力還是很大的。
5、分布式的考慮，可伸縮型問題凸顯。如何透明實現分布式是個關鍵性問題，AOP是技術契機。
6、Web2.0會產生巨大影響力，但Java絕不是唯一選擇。Java要找好自己的位置，同時在平臺上最好能夠更多的融合，如讓JVM支持PHP/Ruby/Python。
7、Web部分競爭激烈，并會持續。EJB3的JSF命運難測。看Web2.0的浪潮了。  閱讀全文

     摘要: 這是擦拭法的本意。
實際上BadClass()實例化以后Class里面就不包括T的信息了，對于Class而言T已經被擦拭為Object。而真正的T參數被轉到使用T的方法（或者變量聲明或者其它使用T的地方）里面（如果沒有那就沒有存根，這里指ParameterizedTyp），所以無法反射到T的具體類別，也就無法得到T.class。
而getGenericSuperclass()是Generic繼承的特例，對于這種情況子類會保存父類的Generic參數類型，返回一個ParameterizedType，這時可以獲取到父類的T.class了，這也正是子類確定應該繼承什么T的方法。
我們應該利用這種特性，這對實現模版方法非常有用。  閱讀全文

     摘要: 為我們的項目寫的一個輕量的分頁API。目的在于將分頁與數據查詢的邏輯完全剝離。我以前看過robbin發的通過detachedCriteria實現的分頁那片貼子，里面把分頁和數據查詢結合在一起了。而我覺得分開更輕量，而且替換也比較容易。但是這個實現中有一個反模式，在邏輯中生成了代碼，無奈之選，為了簡便。其中字符生成可以自己擴展i18n實現，應該非常容易。
分頁實現的接口：  閱讀全文

     摘要: 這是一篇很有趣的文檔，所以摘要一下，其實類似閱讀筆記，好像是3/25發布的：
這時基于對以下人的采訪：
JSF Jacob Hookom
RIFE Geert Bevin
Seam Gavin King
Spring MVC Rob Harrop
Spring Web Flow Rob Harrop and Keith Donald
Stripes Tim Fennell
Struts Action 1 Don Brown
Tapestry Howard Lewis Ship
Trails Chris Nelson
WebWork Patrick Lightbody
Wicket Eelco Hillenius
里面問了每個框架的人6個相同的問題，很好的體現了各個Web框架的不同之處。如果配合Rod Johnson的J2EE Development Without EJB等書中對Web MVC的闡述會更加深刻的理解各種框架的思想和使用場合。我閱讀后很有收獲，所以將全文摘  閱讀全文

     摘要: BJUG的Cleverpig說起Stripes，正好前兩天在TSS上看到Simon Brown的Blog，對它有點感性認識，所以今天就看了一下，說些粗陋的感受：
皮毛上的觀感：
1、使用Annotation配置。將Action影射、返回View、默認Command注冊、是否驗證這些東西都通過Annotations搞，挺有意思。
2、它也包裝了自己的Tag，Tag從感官上感覺很像WebWork的風格（估計Stripes也是過這個來實現bind，和Spring MVC相同吧，不過沒仔細看Stripes的bind方式）。但是它好像很方便與JSTL共用，所以我覺得它可能和Spring MVC類似，把變量拷貝到request里面，而不是WebWork那樣的VlueStack。
3、它的Validation很Cool，用Annotation設定Validation相當舒適。
4、它里面的event似乎挺有意思，也就是說一個Action可以對應多個method，它管它叫Event。現在WebWokr和Spring MVC對這都有支持，但是Annotation帶  閱讀全文

     摘要: 根據生日計算年齡可以通過Calendar實現。最簡單可以考慮get(Calendar.DAY_OF_YEAR)來簡單修正年齡，但是遇到生日在閏年的2月29之后，或者今年是閏年的2月29之后可能出現計算不準，誤差一天。所以還是老實判斷年月日好了。
public static int getAge(Date birthDay) throws Exception {
Calendar cal = Calendar.getInstance();

if (cal.before(birthDay)) {
throw new IllegalArgumentException(
"The birthDay is before Now.It's unbelievable!");
}

int yearNow = cal.get(Calendar.YEAR);
int monthNow =   閱讀全文