摘要: 我用的是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却往往是薄薄的一层门面，很多人就在质疑两者的合并问题。可是robbin曾经进行过一个精辟的分析，虽然两者做的看起来差不多，可是两者的事务属性却不一样，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引擎的接口。…………  阅读全文