JBossDeveloper

I really don't understand all the complaints about Seam, I'm using it (with RichFaces) for almost 2 years and now the 90% of the web stuff I do is using it.

I'm also making a card game for fun using Seam and RichFaces features.

I don't get the point about stateless/stateful too: you can use just stateless beans if you think they are more scalable, anyways I think in most application having stateful beans is very important.

The learning curve is maybe high but if you get some good book (the last one I'm reading is the new Seam Framework - Experience the Evolution of Java EE from Michael Yuan and others) and read carefully the documentation you can reach a good level in no more time than with other frameworks, and when you understand it very well you can use it better, really better, making very clean solutions to most of the problems of web development.

Also RichFaces integrates very well but if you don't know it well you can make completely non optimized code.

After you really understand those technologies I think your work become better and faster at the same time.

My only complain is about the need to restart a lot the AS (that make you loose a lot of time even if you have a very good computer), so I think hot deployment might be improved.

Before Seam I used ASP (long time ago), PHP, JSP, JSF (a mess without Seam).

Another area I would like to have more info about is optimization for huge applications: you can find something on the web and on book but I would like an entire book about this topic covering Seam, JPA, RichFaces and other technologies we use while developing.

Demetrio

Hello,

I'm using Seam / JSF/ EJB3 / JBOSS 4.2 for a professional website with limited traffic and I find the Seam framework necessary if you want to use JSF.

However, I am quite surprised by the poor performance obtained with this solution (heavy load) and I think JSF is more involved than Seam.
So I know what you will say: it is because you don't use the framework correctly... or have you used the @BypassInterceptorsthat to display a table of 100 rows in less than 5sec?)

Today, we don't see benchmarks that show the performance of JSF (with or without Seam), so I do some quick heavy load tests with JMeter. Because I think the Seam team makes a good job, I chose the example of hotel booking developped by Spring (which looks like exemple of Seam...). The advantage is that the same application was developed with Spring MVC / JSP and Spring Faces JSF / facelets. (installed on a tomcat 6.0)

For 100 threads, ramp-up period of 15 seconds and loop count of 50, I request the same simply page (searching page):

1) Spring MVC / jsp : 35-40ms average
2) Spring Faces / JSF / Facelet : it starts at 200ms or 300ms response time then we see after few seconds response time increased to 1s, 2s and 3s ... (with HTTP errors that increase significantly)

My website have the same problem with JSF / Seam.
       
If I don't say silly things, I believe the SeamFramework.org website is using SEAM / JSF / EJB3 / JBOSS technology. The response time of the render page is not extraordinary. For exemple, this topic (with 30 posts) have a response time of 5secs

Did someone made serious benchmarks?

Sébastien
Sorry for my english

We have developed a RichFaces/Seam/JSF/EJB3/JBoss application and it goes slow. It can for sure be improved more, but it shows that JSF/Seam combination is very slow indeed.

Another application we are developing, (first release finished) is a JSF/Seam/JBPM/JBoss ESB/EJB3 application. We have tried improving this alot with html caching and lucene, and it still shows a high load. It is not easy tuning, and the customer complains of the performance.

I spoke with Pete Muir in a BOF in devoxx 08 in december, and he said that the way seam is developed, because of all the interceptors and such, it is the performance it is (meaning slow). He continued to say that they have learned from this project, and that the WebBeans project would be better performance wise.

So I think we can hope that JSF2.0 with Web Beans can be much faster.

We have not done proper benchmarking, but we have 2 teams using Seam in very different ways one (mine) using it with JPA+Seam+Richfaces (JpSeRi), and the other (someone else in charge, but I help him somtimes) uses PlainJDBC+SeamWebRemoting+PlainHTML+JavaScript (PlSeWeRePlJa).

What to guess which one feels way faster than the other?

The PlSeWeRePlJa is the one, and, it easy to see why with something like Firebug or Fiddler: the JpSeRi uses way much more bandwith, it obvious after you think about it for a while, the PlSeWeRePlJa only needs to fetch the data to fill the UI, while the JpSeRi needs to fetch all the tags describing the UI and the data each time (and there is no way to specify real client side caching, something that is extremely easy if you are using JavaScript).

I'm upset that the Seam team seems to have moved onto bigger and better things.  Seam was used as a building block towards where they wanted to be all along - WebBeans. 

Some points I'd like to make from my own experience developing a large-scale application with Seam (not in production yet), following trends on this forum and elsewhere, and generally keeping a watchful eye on Seam's progress as whole.

Seam suffers from performance issues, this cannot be denied.

Documentation is poor.

Seam team community reach-out is dwindling and at times just plain rude.

SeamFramework.org needs an overhaul; it's a nice use for Seam, but it lags behind much better and simpler solutions provided by other big frameworks.

JSF is not all that it's cracked up to be, so you're automatically putting yourself into a bad spot going the JSF / RichFaces or IceFaces route from the get-go.

I hope the Seam team is reading this thread.

Chris Simons wrote on Apr 01, 2009 18:27:



I'm upset that the Seam team seems to have moved onto bigger and better things.  Seam was used as a building block towards where they wanted to be all along - WebBeans. 

Web Beans will form the core API for Seam 3.  So your comment is not 100% true (yet).

Some points I'd like to make from my own experience developing a large-scale application with Seam (not in production yet), following trends on this forum and elsewhere, and generally keeping a watchful eye on Seam's progress as whole.

Seam suffers from performance issues, this cannot be denied.

read this: http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html

Documentation is poor.

I don't agree with this.  The Seam ref doc for 2.1.1.GA is over 600 pgs.  Poor compared to what?

Seam team community reach-out is dwindling and at times just plain rude.

That's true sometimes.

SeamFramework.org needs an overhaul; it's a nice use for Seam, but it lags behind much better and simpler solutions provided by other big frameworks.

tell CBauer.  he won't listen.  Don't you get tired of these errors from the text parser that no other form has the following problems?
Formatting error, wrong position for a backtick.
Formatting error, missing an underscore, instead found a doublequote.
and this wiki system only emails the thread originator, not the other posters.  that's horrible.  nobody listens and fixes this stuff.  it takes so damn long to figure out how to fix the formatting errors that ppl give up this board or the don't format their text which makes it harder to read.

JSF is not all that it's cracked up to be, so you're automatically putting yourself into a bad spot going the JSF / RichFaces or IceFaces route from the get-go.

JSF2 has some improvements coming, like GET instead of POST requests.  JSF1.2/facelets is much better than JSP.

I hope the Seam team is reading this thread.

they may read but don't respond.

JBoss recently shut me down telling me I open too many unsupported (out-of-scope) tickets.  So you pay $3500 for a JBoss dev subscription and the avg company opens less than 30 tickets per year.  How's that for customer service?  What happened to the customer is always right?  Beware...

Do you really think that JEE-equipped, enterprise level, high-performance, 99.999% uptime IT organizations are going to take Redhat/JBoss seriously when they find out this kind of stuff is happening?  Or look at other options...

You can't even edit your posts on this board.  post again and again to fix the typo's...

and what about the fact that there are less than 100 jobs with keyword seam on dice.com?

so if you leave your present employer for whatever reason, you will most likely be forced to re-learn an entirely new JEE stack if you remain a JEE developer.

b/c virtually nobody uses Seam in corporate tech stacks.  and Seam is now officially almost 3 years old since 1.0.0.GA was released...

counter argument?

they say there's traction but if it's not on dice.com, it doesn't count...

Why are there so few IT shops in North America using Seam?  Is it Seam, is it JBoss, is it Redhat, is it the support contracts/pricing?

I'm sure Redhat is thinking about this.  Why is there no Advance Seam training available yet?  Seam has been out for almost 3 years. 

Web Beans will form the core API for Seam 3. So your comment is not 100% true (yet).

That might be true; but this also constitutes a large re-architecture of the Seam framework.  Do you really expect RedHat to make Seam 2.0 and Seam 3.0 truly compatible?  So after only version 2.1, they're now solely focusing on WebBeans and then - at some point far in the future - building a Seam 3.0 based off of WebBeans 1.0.  Check JIRA, there are no major releases planned/scheduled until Seam 3.0.

I don't know about you, but I don't like the thought that our Seam 2.1 system will be old school within a year and a half and that support will be even harder to come by.

Appreciate your comments, though.

Aw come on, the chart is for Spring the season, not the framework! 
Try this:

My Link

Spring vs Seam vs bla vs bla is just religion. They're suited for different applications. If you don't know them all inside out, saying X is better than Y is jut not valid. Of course both Seam and Spring and X and Y have flaws, choose the one best suited for your application.

Regarding Seam in professional use, there is a link on this very page with lots of pages done in Seam in professional use. Obviously some people have managed to write Seam applications with all diverse constraints, maybe they just knew Seam good enough to succeed?

Regarding charts for this and that what is the biggest are not very useful. Even if framework X is totally superior to framework Y, people must have the skills to USE X (or Y). The vast majority of people will use what the've used before, since they already know that. Maybe the learning curve for Y is less steep? Should you then use Y, although inferior to X? I think Churchill put it in another way: The greatest argument against democracy is talking to the regular guy on the street....

dice.com does not lie.  most recruiters have never heard of Seam.  b/c there are very, very few req's for Seam.  b/c there are very, very few JEE shops using JBoss and/or Seam.

wasn't Spring new as of 2003/2004 when Rod Johnson wrote J2EE Development w/o EJB?  but it was innovative (AOP and DI), cost efficient and effective enough as a lightweight framework that its adoption rate sky-rocketed in JEE shops worldwide (along with Hibernate).  Seam is very innovative but very little adoption still.

I'm not saying Spring is better or Seam is better.  that would be ludicrous.  these are complex systems, not apples and oranges.

I'm saying that after 3 years, which is a very long time in the Java space, the adoption rate for Seam in EE environments is miniscule when compared to Spring/Hibernate and Struts/EJB2.x.  That should be seen as a failure on the part of Redhat/JBoss b/c I do think that Seam is a very good framework for a variety of reasons.

After 3 years, there is no advanced Seam training available today.

here: https://www.redhat.com/courses/jboss_dev/: JB170 JBoss: SEAM Essentials

The casing is even wrong on the official redhat.com site (it's Seam, not SEAM!)

horrible.

case closed.

I would love to hear Ted Neward's take on Seam.  He most likely has a non-biased view as he is a .NET and Java bigot...

You said 'case closed' and you still respond... like talking to yourself?