seam再见了

大概做的不是互联网吧，办公室里的行业软件一般对UI的效率要求不高，有的甚至没有UI，如果并发访问太多的话就看出差距了。

我没有使用到ejb，仅从seam+jsf这样组合方面我没有感觉到是seam如此的慢。
seam有以下的增强，当然也就会产生效率消耗：
1.seam给jsf框架的变量解析链增加自己的变量解析环节，也就是每个变量处理都会经过seam变量解析处理！
2.seam在jsf的生命周期的每个阶段加入了监听器，使得每个阶段有一点点效率损失！
3.seam对jsf的backing bean 也就是seam的 component加入了元数据定义（大量的@...），那么处理这些元数据定义的机制就是利用了aop，在每次component的方法调用时刻，其实都会去执行包在component上的层层拦截器（seam的拦截器，和spring的很像，也可以自定义拦截器，加载到backing bean/component上）！
4.还有一些，我没有说到

当然了我相信你的设计是面向企业用户的，不是互联网用户，而且你的框架可以说是最低效的做法！
1.facelet的加入会比纯标记更慢
2.ajax+jsf的机制每次对一个或多个区域的操作都有可能多次请求jsf后台，导致jsf每次都要经历一个完整的生命周期处理，所以要合理并细心的控制ajax+jsf的代码。
3.seam的加入引入了消耗。
4.jsf本身不是一个非常高效的平台，由于它的监听机制导致组件的频繁访问，尤其要当心你的程序在调用组件的isRendered的方法时是否有资源消耗的操作，因为isRendered往往会在一次请求中频繁的被访问到！
5.ejb的使用也有更高的资源消耗。


但是这些共同使用可以打造一个高效的，复用性强的开发环境（请确定是ejb3），但是就不要在web环境下考虑了肯定会慢的。

不知楼上的各位达人是否做了项目的充分的性能方面的跟踪和调优？

这东西运行个DEMO都这么慢

我现在也在用jsf+ejb1.2+jsp+jstl+servlet

我正在看ejb3.0和seam。但是具体的应用还是开始做，icefaces + ejb3.0 + seam。

还有点，个人觉得seam对有状态会话bean的管理还是不错的。至少维护它的生命周期，对话生命周期。

附件是jboss seam的一个压力测试报告，比较旧，但是可以参考看看。

我觉得不是你讲的那样,我们一直都在用,而且我们的系统是廷大的那种,每天流量应该也在50到100w,而且广告策略下载计算量都是相当大面复杂的,扣费也是要求错误率很底的那种,

 

Seam和RichFaces是可以调优的， 不知道楼主遇到什么具体问题了， 可以交流交流。
Seam的BypassInterceptor这个Annotation是要非常注意使用的， 如果忘记这个， 性能不可能好， 每次调用都10个8个的interceptor去拦截能好么？
这个是正确使用的问题， 不是Seam本身的问题， 还有RichFaces的一些特性其实前端未必用到， 推荐的做法是能用标准component解决的尽量不用richfaces， 另外通过YUI的测试报告来看， 尽量使用RichFaces的单文件js和css配置，减少HTTP请求次数。
我说的这点也是献丑， 我也在研究提高Seam的性能， 可以交流交流。
我觉得Seam之于JSF并不比Hibernate之于JDBC差， 相反， Seam很多地方做的我觉得比Spring优秀。