摘要: 我用的是Eclipse 3.2，操作系統是WinXP SP2。
需要把eclipse\plugins\org.eclipse.swt.win32.win32.x86_3.2.0.v3232m.jar里面的swt-win32-3232.dll解壓縮出來拷貝到WINDOWS\SYSTEM32里面。
然后就OK了。
是在Eclipse里面運行Springside的ANT Task的時候，如果需要通過console輸入交互信息，則會報這個錯。應該是因為Eclipse的console依賴于那個本地庫，而平常我們安裝Eclipse不會拷貝那個庫。大概如此了。  閱讀全文

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

     摘要: 今天TSS和InfoQ都轉了一篇Spring與EJB3的讀后感，我就看了下，標題和介紹滿吸引人的。內容嘛其實有點不過癮，但是先記錄下來吧。
http://www.devx.com/Java/Article/32314/0/page/1
總的來看Spring+Hibernate與JPA很相似，它們都是基于pojo的持久化。
Hibernate Session和JPA Entity Manager基本上等價，但是要記住他們的兩個重要區別。Hibernate session是一個實體緩存也是一個ORM引擎的接口。而JPA中這兩個概念是分開的。Persistence context作為緩存而entity manager則作為ORM引擎的接口。…………  閱讀全文