发现JBoss Seam很棒呀！有用Seam做过项目的吗？

1.这几天为项目加入了facelets模板机制，可以很好的解决密密麻麻tag的问题，facelets的行为解决了jsf渲染层面的不足。
2.打包ear只是jboss一厢情愿的做法，完全没有必要这样，我现在的做法，Tomcat底下跑facelets+seam+myfaces+spring+hibernate,利用seam的集成测试，可以把单元测试提前到表现层来测试了，测试的范围更加扩大，而且seam最酷的地方就是和spring良好的集成，spring里面可以直接注入seam组件或者作为seam组件存在！

看来robbin也很久没有看spring了。要注意的是，每当写到“不象spring那样...贬义词...”时，建议还是去看看spring最新的文档，看该缺点是否还在，要么就注明“不象spring（版本号）那样。。。”。曾经有人不注意这点，结果被spring team耐心地教育了一番。

另外，seam也是用了OpenSessionInView。如果说讨厌的话，两个frameworks都适用。俺用了很久，倒也不觉得有什么问题。

虽然我觉得Gavin King人不怎么样（以前），但对事不对人，俺也觉得seam是不错的东西。要是和spring比的话，因侧重点不同，不好直接比较。

我很期待被你耐心的教育一番，我很想借这个机会讨论讨论Seam和Spring 2.5，真的。



还是有很大不同。Spring的OpenSessionInView并不是一种被Spring官方推荐的模式，在View中延迟加载数据的时候，已经离开了事务的控制范围了，在某些特定的情况下，会造成数据不一致的问题。特别是有远程调用的情况下，更需要手工处理Session，确保远程调用方法结束的时候就立即关闭Session。Seam看起来没有这些问题，当然我现在还不太清楚Seam的底层实现机制。但是官方文档上面这是一个Seam被宣传的亮点，那应该就不会出现Spring那些问题了。



你可以说说看我对spring有哪些贬低的话，我已经看过了一遍spring2.5的文档，确实很想知道现在spring有哪些我还不知道的，特别不一样的东西。

自从RoR流行以来，EJB时代所强调的一分二分再分变为了一合二合再合，Java界合下来的结果就是Seam。
这其实是比较务实的，毕竟大多数项目搞那么多层是没有必要的，来来回回绕那么多弯，最后也未必真能复用到哪里去。
MVC已经足够了。这一点上，RoR已然作出了回应，Seam也是大势所趋。

JSF这东西，以Struts这类的习惯性思维来衡量是不行的。它本质上是标准化平台性质（Sun似乎就喜欢搞这种事情），大家可以对其进行扩展改造，以适应自己的需要。所以如myfaces、RichFaces、ICEFaces、AOM这类的东西才大有可为。

坚守Java领域的同道，大可以考虑好好研究应用Seam。虽然初始开发效率还是不如RoR（大概有1/2），但深入下去静态语言的优越性会慢慢体现出来，最终效益如何未为可知，还待大家实践。

每次来JavaEye，不想跟别人较什么劲，但是每次总会发现一些个无知的人在说一些无知的话。不明白lgx522说的所谓什么“自从RoR流行以来”是什么意思，RoR对于业界的影响最大的无非是敏捷开发和默认大于配置的思想而已，如果单纯从技术角度出发，RoR还远没有走在技术的最前沿。

不知道lgx522了解不了解目前Java EE的现状，Java EE6预计下半年不久就会发布，其中最引人注目的是EJB3.1和JSF2.0以及WebBean，WebBean就是Gavin King提出来的，目前Gavin King跟Bob Lee共同支持和制定WebBean的相关规范，草稿已经发布。seam目前的角色跟Hibernate很相似，JPA规范是Hibernate实现的一个子集，JPA可以使开发者免于底层的ORM实现，所以无论Hibernate,OpenJPA,TopLink都可以使用。seam也是同样的，是WebBean的一个参照实现而已，所以最终的结果不是seam，而是WebBean。

虽然最终的Java EE6会是什么样还不得而知，但可以肯定的是，它的最终目标是使Java开发更加简化，而且更加贴近开源社区。目前的seam2.1已经可以整合wicket,所以将来Java EE6对于目前流行的开源项目会是一个更好的整合点。几天前跟robbin还在帖子上讨论Java与RoR的前景，我选择从RoR回到Java，可以看到Java的进步，更看好目前Java界。

我看你也挺莫名其妙的，lgx522明显是支持Seam和Java EE的，就说了一句RoR如何如何，就踩了你的尾巴了？RoR走的路子和Seam是不一样的，Seam这种强调服务端组件状态的框架完全不适合互联网应用，但它特别适合企业应用，而RoR是反过来的，这两个的应用领域不一样，并不冲突吧？

何况我这个帖子是探讨Seam和Spring2.5的，请你也不要随便跑题吧。 有空就多发表发表你关于Seam和JSF方面的实战经验，谢谢。

支持，看了许多web框架，感觉seam对于web开发的问题域考虑的非常全面。给予一定的时间难保变成像hibernate统一orm那样一统web框架 ：）

seam和spring最大的区别，就是seam的组件可以是有状态的（或者说状态丰富的），而spring的bean则是无状态的。spring的bean并不记得上一次调用它的时候，它具有什么状态。但是在seam中，一个组件在它生存期内，是可以有状态的。Gavin认为人们在开发spring+ hibernate时遇到的阻力主要是来自于hibernate是有状态的，页面表现层也是有状态，但是spring却是无状态的。是这种有状态与无状态之间的不对口，导致orm的能力不能全部发挥，导致了从表现层到服务层的时候状态转换的麻烦。所以seam的理念，就是stateful。

同时为了便于开发，seam也注意了其它地方。比如，
1 大量的使用annotation，减少xml，
2 使用 事件机制， 让方法解耦，
3 集成很多方便使用的技术，richfaces, pdf, rule based 权限机制，等

seam瞄准了企业开发，和jbpm无缝集成，加入 business scope就是专门做这事的。

seam和spring很不一样，使用的时候，要有一痛苦的观念转变过程。


另外，关于OpenSessionInView的问题，seam的文档里好像有专门的说明。传统的opensessioninview不能处理这种情况，当view生成完后，关闭session的时候，可能有一部分状态没有能够成功的持久化到数据库，但是由于view已经生成，用户也无法得到持久化不成功的消息。 seam 没有使用传统的OpenSessionInview。它的hibernate session和 conversation及jsf之间存着联系。当conversation开始时，会开始session和一个事务，在jsf的 Invoke Application phase之后提交事务，保证数据的持久化。而之后这个session并不会关闭，她会开启到conversation结束，而conversation是能跨越redirect get 的，所以后面get 生成view时，也不会出先 LazyInitializationException。 hibernate session可以跨越多个请求，比opensessioninview还要长。

Seam研究过一阵子，感觉是jboss各种技术的糅合体，更多像是一种j2ee企业应用开发模式而不是开发框架。另外，讲究分层、架构、复用和模式与代码量大、开发周期长、架构烦琐等没有直接关系。

刚才写了一点，没登陆，白写了。

对JSF和Seam都因为恐惧而没有深入接触

习惯了随心所欲的控制web界面上的各种元素，总觉得用拖拖拽拽的JSF会束缚WebUI的开发。
而以前开发EJB时的不爽的体验，也对JBoss失去了兴趣，最大的痛苦就是deploy；

看来星星还是那颗星星。

要不要跟风学习一下JSF和Seam呢？