Seam生命周期

楼上有点过于激动了。

seam的好处，坏处我都说，而且我也说清楚了。richfaces的性能是问题，conversation长对话的性能是问题，jsf 的生命周期是问题，其他不一一列举。

seam的好处呢，正式集成诸多组件，让开发更容易。

楼上一个劲说seam2不要用，你倒是说出个1,2，3.bug 多，你举一个没解决的瞅瞅，对待技术不要武断。

大家怎么说说话就都怒了呢!?

话不投机，说不下去了。你要是有兴趣我们可以单独聊呀。

如果大家站在Gavin King的角度，包括研究Gavin King这个人，也许很多问题就有了答案。

扬长避短吧，任何一种技术的出现都有其初衷。不要轻易否定，在否定之前认真思考，就事论事。

你是指Gavin King想要做一个web框架，来真正的发挥hibernate的能力吗？

性能一直是个问题

好像没有提及Seam给测试和OO设计上带来的便宜，不好意思，还没有实际的使用过，目前来说感触比较深的就是这个。从架构上来说因为是最贴近Java EE规范的，所以可伸缩性很强。但是因为Java EE本身的大并发就有缺陷，所以性能上的确应该不强。
总的来说，感觉Seam从纯粹技术角度来说，方便了开发和使用，基于标准和OO，代价就是复杂的实现原理和性能，这个应该和EJB是一个意思
目前没有太多接触，发言可能有误，希望楼上各位指正

从成熟度看，Seam3 和 Seam2 差很远。

我们现在一个项目，客户要求迁移到 Seam3，结果发现了很多问题，除了发现大量 BUG 外，就是 Seam3 本身并没移植所有 Seam2 功能，特别 Seam UI 相关的部分（jsf, excel, pdf, mail）。

Seam 3 的开发令人担忧，最近的 Seam 3.1.0 Beta3 中将几个模块（config, servlet, catch）合并到solder，按照官方的说法，3.1 可能是最后一个以 Bundle形式发布的 Seam 3产品。之后，persistence 丢给了hibernate, wicket 丢给apache wicket，rest 丢给 resteasy,等等， 而drools 这些还没发布的模块，直接死胎腹中。。。相应的 Seam 3 模块版本不再统一（或许那时不应该再叫 Seam了）。

Seam 的优势在于 Stateful（也就是它的状态管理）， 用了Seam 之后，再用 Spring， 我怎么都不习惯（当然 Spring 也在试图加入 Conversation）。

seam 做的网站也很多，做内部系统可能更适合一些，seamframework 网站本身就是 seam 2 wiki example。

RichFaces 生成的页面代码的确够吓人，如果可能，尽可能的使用 a4j，rich 高级组件应该不怎么样。

我连Java都不想用了.
Seam框架, 很炫, 大家也知道 不适合做前台交互的互联网项目,搞一些内部系统开发是挺快.
想用Scala了,
但公司现在没有开, 暂时忍着用JAVA.以后我就能带头用