Hi,

I'm a developer on a medium sized application and we are using SEAM. Admittedly we are not using a lot of SEAM functionality but we do use SEAM for simplifying our web module.

We don't use extended persistence context, and we still use Spring for services.

So all our domain objects are detached when they reach the web layer and are passed back to the services to persist/merge.

After a bit of research we decided that SEAM's extended persistence context does not work well in larger applications, or maybe just applications like ours. It also allows for bad coding practices (programmers not understanding what's going on, ie. too much sql gets issued due to lazy loading etc etc). Essentially we have used SEAM as a way to reduce the amount of xml needed by JSF to register all our beans. As well as provide the necessary Scoping mechanism instead of passing around parameters and session variables etc.

We don't use the extended capabilities that SEAM adds to pages.xml as we are trying hard to stay away from string based abstraction. (Which is hard when injection is name based instead of type [why this can't be type based like spring I'm not sure, I've even contiplated patching seam to allow this] ) Essentially we want to be able to follow the logic in our code. We don't want to look at some rules file to see where we are navigating too. So we wrote our own navigation manager that allows this. This navigation manager also takes away the need for developers to understand exactly how conversations work etc. They just know that what they do inside one 'module' (our own term) they cannot access in another 'module'.

Don't get me wrong, I think SEAM is a neat technology. But for real world applications it does over simplify some very complex ideas that really should be understood by the programmer not just allowed to 'make it work'.

I'm a developer in a small 'company' and we use seam...or we're trying to use Seam. Web do medium CRUD application and it's takes forever to develop without problems. Then sometimes jboss crash, then we used seam early version and it works only on jboss 4.0.5, after that we used seam 2.0.2 and runs on 4.2.2, the old app is impossible to port...we have 2 different jboss server in production now. Then the community, the maximum number of users online here is 25, or even 30 but never more. I rarely saw a useful answer. Sorry about that, Seam could be a neat technology like Tim says, but for now it's not rapid and agile development like they said.

Hi, I'm also a developer in a small company. We've chosen Seam to build a new website, and though the learning curve has been quite slow during the first months, it's been very rewarding. We've now finished our first site, which has been in production using Jboss and Postgres for about a year now, and we're working on rebuilding our old main website using the framework we've developed for our fist application. The development is now really fast and efficient.

The website we have in production running with Seam is not that big, with about 3000 hits a day, but we have no issue at all regarding performance, although we do have a lot background task being processed every day.

So all in all, we're very satisfied with Seam.

Tim Evers wrote on Mar 18, 2009 05:40:
Essentially we have used SEAM as a way to reduce the amount of xml needed by JSF to register all our beans. As well as provide the necessary Scoping mechanism instead of passing around parameters and session variables etc.

We feel the same way; although we've only been using Seam for a few months, our impression is that it's not nearly as easy to use as it's made out to be. Our strategy is to use as little of it as possible, mainly to fix the issues with JSF.

Hm.. that's disappointing to hear. I ran a site a couple years ago with average 70 concurrent users and Seam was handling it without a problem. It was also using EJB3 session and entity beans, where the backing bean is the session beans. That was when Seam was BETA.

Can the developers of Seam make some comments about all this?

On the side note, there is another open source framework for JSF/JPA that's much lighter called MakeFaces. It takes care of all the annoying things of JSF but doesn't do as much fancy things as Seam, perhaps it will one day I can't say. I'm a small contributor to it at my previous company. I've used it extensively professionally and on my own projects. I also know several large government and insurance projects are using it. Let me know what you think of it.

MakeFaces url: https://makefaces.dev.java.net/

Here's a personal app I built using it. http://myasset.no-ip.org

Hi, I appreciate this thread very much; I'm very much interested in other opinions about Seam.

Luke Simon wrote on Mar 18, 2009 08:35:
Sorry about that, Seam could be a neat technology like Tim says, but for now it's not rapid and agile development like they said.

I fully agree with that. I've chosen Seam after some weeks of research on Java web frameworks because it's the one that promises less configuration issues regarding persistence/database access - in all other frameworks, you have to code your persistent objects twice (Java class, hibernate xml), that's the gap that Seam bridges (or the seam that mends them together). But I'm really disappointed on 2 things:

• it's far from RAD - after starting the project by generating the UI via reverse engineering from DB you're left standing in the rain, no more support for generating the files for new entities. See my full length post

how to come to RAD

which I plan to post on JBoss tools forum and create JIRA issues

• It's a long and steep learning curve. It's hard to understand the concepts behind which - in my opinion - are not explained in depth in the documentation, but which is essential to understand if you do something that goes beyond the simple CRUD examples

BTW, what are your resources (forums, books) to learn seam?

Regards, Robert

I am building, and have built, some very large enterprise applications for various insurance companies. All have used Seam. Having come from Struts and J2EE environments, I really appreciate everything Seam does. I hear a lot about how steep the Seam learning curve is. I found this to be true only because I didn't understand some of the underlying technology as well as I thought I did. The curve also became much less steep once I studied all the examples (I steal from them on a regular basis!), read the reference docs, and read Allen's book a couple of times. My only gripe is the difficulty in integration testing when using Maven -- but that's probably because I don't understand Maven as well as I should -- although a complete Maven EAR example using integration testing would be great to have!

We find Seam offers a good mix of (fairly) rapid development, good performance, great tools, a neat language (yes we like Java and JBoss EL!) and plenty of useful libraries. We've just launched a new web based CRM application using Seam and deployed on Amazon EC2. Feel free to sign up for a free account (www.javelincrm.com) and have a play. It should demonstrate Seam can be used to create nice UI's that compete with anything from the ruby camp. There's also some live searches in their that demonstrate the speed that is possible.

We are careful with how we use Seam in that we minimize long running conversations and avoid things like page scope and s:links. None of this has been onerous and probably makes for a more familiar web app experience anyway. Main dislikes are the weight of Richfaces and the ugly markup it uses which makes styling the components difficult. We use stateless session beans to encapsulate data access and other core service functionality in one place. We're using JPA entity beans via the seam persistence context. However the hibernate extensions are too compelling so we've used a lot of these and I'd have no issue recommending Hibernate.

Regards, Duncan

Well, if comparison with other frameworks is allowed, I have to say I would like to see Seam grow in AribaWeb direction (100X less code than Rails may be an exaggeration, but it certainly gives you a hint of how easy java development should be) , seam-gen is just too simple to be of real help for real applications (just look at what AribaWeb MetaUI can do), and I really would like to see an API for programmatic navigation (no XML please) like the one offered in AribaWeb (very similar to the ones offered by Wicket or Tapestry, page object based navigation is a must for really complex applications. Seam has already recognized that JSF navigation is limited by creating the .page.xml files, all that we need now is one more step to get rid of all those xml files, and finally have strong typed navigation (and keep xml based navigation for those building simple stuff).

Validation is another big issue, since Hibernate entityManager.persist does not behave in in a way consistent with other JPA implementations (it validates stuff to soon), it is hard to write code that deferrers validation until the end of a transaction/conversation, and since there is no way to get the list of objects to be inserted/updated/deleted it is impossible to truly write generic code for validation (I really hope the hibernate team realized this before they try to integrate JSR 303 with Hibernate).

Please don't get me wrong, I really do like Seam and Hibernate, but I think it is only half of what it could be. JSF based development for real world web based OLTP applications (not just mostly read only pages) is still not as easy as it should be, and there is really no reason it shouldn't. Seam needs to focus on making everyday tasks really dead easy, with almost no code.

I've been using Seam professionally for over 1.5 years. I come from a Powerbuilder and J2EE (Struts/EJB2) background.

Seam has a very steep learning curve even if you are proficient with Eclipse or similar Java IDE and Java 5 (specifically generics and annotations). Because you must simultaneously learn JSF, Facelets, EJB3, JPA, Hibernate (or other persistence provider), Richfaces/ICEfaces. It's a very powerful and intimidating technology stack.

If you contact Redhat sales/marketing for a list of customers who use JBoss AS, it's not available. Seam has been out almost exactly 3 years. That's very long in the Java space.

If you have functional requirements that demand workspaces and conversation scope for multi-tab applications, Seam is a good choice. Likewise for jBPM integration with JBoss AS. Not too convinced with the performance but I do know there are some performance tweaks coming with JSF 2.0 as well as Seam 2.1.1.

Richfaces is very interesting and powerful and very useful for live validation and other cool Web 2.0 effects (e.g., rich:modalPanel).

We have a few internal-facing apps in production but if you compare the number of jobs available on www.dice.com compared to Spring and Struts, for example, Seam is WAY BEHIND in terms of adoption and traction. It's really bad if you consider the framework has been out for 3 years and you can use it with non-JBOss app servers like Tomcat and Weblogic.

If you can get used to annotations all over the place (like you may have gotten used to writing AOP code in xml for Spring apps), then perhaps Seam is your thing.

I still have reservations of the whole Java EE productivity disaster when compared to .NET. Perhaps things will change with EE 6...

We are using Seam to develop an animal tracking system. Our client will be going live in early June.

Yes, there is a learning curve, as there is for any other advanced technology. It is difficult to find developers who know Seam, or, for that matter, JSF or JPA. There is certainly room for improvement in the the product's documentation and in other learning resources.

It is important to take into consideration that Rich Internet applications are a recent phenomenon. Growing pains are unavoidable, and are the price of being on the leading edge.

Jboss and Seam stand among the leaders of the Enterprise Java platform. With JSF 2, Web Beans (JSR299), and Beans Validator (JSR 303), the offerings should be even more compelling in the near future.

Onward!

1) big difference b/n animal tracking systems and our four-page CRUD Seam apps vs. amazon.com and ebay.com using Seam stack. When will that surface? When will high-transactional, multi-node (vertical and horz clustering) with Seam stack come to be with the big hitter web sites? Fortune 500 external facing websites like ticketmaster.com. It's been 3 years, like I said. .NET and Spring still rule this space. Will Seam take over market share here? Unlikely.

2) The term AJAX was coined when? 2005. dojo and DWR were around several years ago.

3) With SpringSource's recent acquisition of G2One, JBoss/Seam was some very serious problems.

4) This forum is worse than the original jboss.com forums b/c the replier to a thread (non-originator) does not get emailed if there is a reply to their reply (like literally all other forums in existence). Major oversight and people get left hanging when they need help. How long will this last?

5) Stateful vs. stateless architectures. State replication in a JEE cluster. Performance considerations. 2PC/XA distributed transactions. I'd like to see a real case study on a real client's high-tx site (note the JBoss/Dell fantasy one).

6) if you're going to be building simple CRUD apps, you might as well stick with RoR or .NET, not Seam. Seam is fun to work with and it's interesting, but the learning curve is way too steep. And how are you going to find/hire a Seam dev with experience nowadays anyway? It's almost literally impossible.

Ron Ramirez wrote on Mar 19, 2009 16:32:
1) big difference b/n animal tracking systems and our four-page CRUD Seam apps vs. amazon.com and ebay.com using Seam stack. When will that surface? When will high-transactional, multi-node (vertical and horz clustering) with Seam stack come to be with the big hitter web sites? Fortune 500 external facing websites like ticketmaster.com. It's been 3 years, like I said. .NET and Spring still rule this space. Will Seam take over market share here? Unlikely.

Maybe, maybe not

2) The term AJAX was coined when? 2005. dojo and DWR were around several years ago. 3) With SpringSource's recent acquisition of G2One, JBoss/Seam was some very serious problems.

Well, if a better language is what we are looking for, in that case I think Seam guys should go after Scala (It even looks nice: Scala Seam) ;-). AFAIK Scala is much better than Groovy. Another thing JBoss guys could do I just buy the company behind ZeroTurnaround, that really would give them an advantage.

4) This forum is worse than the original jboss.com forums b/c the replier to a thread (non-originator) does not get emailed if there is a reply to their reply (like literally all other forums in existence). Major oversight and people get left hanging when they need help. How long will this last?

I totally agree.

5) Stateful vs. stateless architectures. State replication in a JEE cluster. Performance considerations. 2PC/XA distributed transactions. I'd like to see a real case study on a real client's high-tx site (note the JBoss/Dell fantasy one).

Me too.

6) if you're going to be building simple CRUD apps, you might as well stick with RoR or .NET, not Seam. Seam is fun to work with and it's interesting, but the learning curve is way too steep. And how are you going to find/hire a Seam dev with experience nowadays anyway? It's almost literally impossible.

Forget about RoR, try AribaWeb it is 100X better than RoR and Grails (and you can code in Groovy if you like), and I think it is what Seam should integrate with... it is either that, or reshape seam-gen and JSF 2.0 to work like that. I think Seam really needs to re-focus on its roots: Make JSF/JPA development as easy as possible, with zero turnaround, and for that, sadly, I think that EJBs and JSF XML based navigation are just dead weight preventing Seam from flying as high as it could.
I really think that Seam has the potential to be better than Ariba, because Seam is standards based, and that really counts in many companies, and also means that more literature and training resource will be/are available, but it needs to make it really easy to work in the standard way, so far, it seems like the creators of the standard stuff just does not care about ease of use, it is like they believe they are going to be use just because they are standard, they are just recently realizing that if something is hard to use, it is just going to be ignored. Seam really simplified a lot stuff, but only for simple applications, when things start getting complicated, Seam looses a lot of its ability to effectively manage the complexity (Nested conversations for example, are just flawed and there does not seem to be an easy way out of that)

AribaWeb is very cool. Never heard of it and it's been out since 1999. that's pretty weird with all the googling and reading I do.

AribaWeb has been a commercially deployed component of Ariba, Inc's network services (e.g. Ariba Supplier Network, Ariba Discovery) and On Demand Spend Management application suite since late 1999. The framework evolved steadily in dozens of releases over that time, and was first released as Open Source in May 2008.

and no books out on AribaWeb on amazon.com? this website is so damn slow...

Guys, back to the topic, In the urls that you posted, all the applications that I saw don't use Richfaces. Nobody uses Richfaces with Seam?

Question to all, do you know Javascript too or not?

It's only a question because Richfaces use Prototype and Scriptaculous, or sometimes JQuery, nobody of you who knows these javascript libraries feels like: 'hey, I can do this without strange tags with JS in 2 lines of code!'. With Seam remoting I have to write interfaces and tons of code in surplus just for a simple ajax call. Then the converter for comboboxes, why? all objects have a toString() method!

There's someone here that like me comes from PHP/Ruby/Perl world? How do you feel with Seam? I'm interested in a serious comparison, with no prejudices like j2ee is enterprise and all others must die :)

Luke Simon wrote on Mar 20, 2009 13:10:
Guys, back to the topic, In the urls that you posted, all the applications that I saw don't use Richfaces. Nobody uses Richfaces with Seam?

I have always wondered about that... (I do use Richfaces, I guess that is because I just don't like Javascript)

Question to all, do you know Javascript too or not?

I know Javascript, but not a lot.

It's only a question because Richfaces use Prototype and Scriptaculous, or sometimes JQuery, nobody of you who knows these javascript libraries feels like: 'hey, I can do this without strange tags with JS in 2 lines of code!'.

Well, jQuery can do a lot of things with almost no javascript (that is why I like it a lot), but in general, in my experience one needs to write more lines of code with the javascript approach than with the JSF approach (and also, the issue with javascript is that if you write to much logic with it, you run in to the risk of forgetting that you must never trust your clients, and then forget to have validation code on the server side, and so you become an easy target for hackers).
Of course, a big problem right now is that to write a JSF component is just many orders of magnitude harder than hack a solution in javascript, one just have too do a quick Google search to realize that, I hope that JSF 2.0 makes creating AJAX enabled components a lot easier, but I wonder if it isn't too little too late (just compare the amount of code vs features in ExtJs vs Richfaces or ICEfaces, or try to find a tutorial in internet that makes you feel that it is easy to write an ajax enabled JSF component, both Ricfaces and ICEfaces are blackboxes when it comes to creating you own components, that may change with Richfaces CDK, but again, maybe it is too late).

With Seam remoting I have to write interfaces and tons of code in surplus just for a simple ajax call.

So you write no server side code? you connect directly to your database from Javascript? I guess then you are safe from crackers because they think it is so easy to destroy your database that they do not even bother trying ;-) (interesting approach, but I 'll keep using Seam WebRemoting and Ajax4Jsf, thanks)

Then the converter for comboboxes, why? all objects have a toString() method!

The converter is not only to convert from an object to a string, but to convert from a string in to an object, all objects do not have a parse method... or do they?

There's someone here that like me comes from PHP/Ruby/Perl world? How do you feel with Seam? I'm interested in a serious comparison, with no prejudices like j2ee is enterprise and all others must die :)

I think that seam, as it is right now, it is just not agile enough (thanks EJBs!), specially if you com from a PHP/Ruby/Perl world (or even a plain write it all in the JSP file world). I really think that the priorities for the next version of seam should be:

1. zero turnaround development (for any code on any layer of the applications, for components and for entities)
2. make seam-gen powerful enough to be considered a functionally complete crud generator (ask Richfaces team to help build a really stunning UI for seam-gen applications)
3. improved validation, that plays well with AJAX (for this, ask Hibernate team to fix the entityManager.persist too early validation) and that works for persisting new objects (validate for insert), updating existing objects (validate for insert) and removing existing objects (validate for delete) and that can be called on demand (validate all pojos with new, changes or that will be deleted in current entityManager), or transactionally (on commit)

Of course, Seam has other advantages, I think that in general the kind of architecture that Seam proposes is good (specially if you do not want to build and easy to crack and destroy website), but it really needs to improve its agility, I waste to much time waiting for my application to restart each time I make a change, and I hate having to violate OAOO/DRY each time I have to write validation code (In my experience must PHP/Perl developers do not care much about good architectural principles (Ruby developers do care, but I just prefer languages with static typing), but of course, you might be the exception).

So, anyone here know or use anything else than Seam?

Yes, lots of other stuff... but I fail to see the goal of your question...

Francisco Peredo wrote on Mar 23, 2009 16:09:
Yes, lots of other stuff... but I fail to see the goal of your question...

Ok, Francisco, I've got your answer...but anyone else? only 1 answer? wow...great community!

So sorry we didn't all rush in to cater to your needs. Your opinion of us is very important ;-)

I've done home-rolled frameworks, Struts and Spring Framework before Seam.

I got around the no support for regenerating entities by hacking up the jboss tools templates. I made the generator generate MyTableGenerated.java, that is annotated with @MappedSuperClass rather than @Entity, I then add my own MyTable.java entity with next to no code in it (90% have none at all). If I need to change a property in the base class I copy it to the main class and then edit hibernate.revenge.xml to exclude generating that property in the future. It saves a lot of time on simple crud screens, however for tables with lots of complicated relationships I usually create my entity from scratch as the defaults are almost never correct. If I add columns to existing tables all I have to do is generate-entities and add in a textbox (or whatever).

Nicklas Karlsson wrote on Mar 23, 2009 21:02:
So sorry we didn't all rush in to cater to your needs. Your opinion of us is very important ;-)

nobody really cares about stack (API) developers really. redhat may eventually file for bankruptcy or get bought out by another larger company. .NET rules all (reality).

;-)

don't you just love the cute grins?

fix this damn board so we get notified of posts man.

Luke Simon wrote on Mar 23, 2009 14:45:
So, anyone here know or use anything else than Seam?

alternative to seam is https://makefaces.dev.java.net/

I used .NET in 2001 during it's BETA stage and I was impressed then. That was before my professional life. My first job was a JAVA web developer and boy was I disappointed at how crappy JAVA web development was. At that time 2002, the JSF specs just came about and at first glance I thought we finally have something comparable to ASP.NET, but nope... it was until 2009 that JAVA web finally caught up to how .NET WAS back in 2001. I'm guessing .NET has improved a whole lot the past 8 years so filling in the gap, I think we're still way behind. That explains why there are so many companies adopting .NET these days.

I've been contemplating the past few days about investing my time in seam. I have used it on a project in 2006 and I really liked it. I think it would be something I'd invest more time in just for fun if I had extra time, but professionally I think it might not be worth it at this time only because no companies out there are adopting it. Although, I seriously don't think the learning curve is as steep as people here say it is and I seriously don't find spring better with all the XML crapfiguration. Could it be because most people are not accustomed to the component based way of thinking yet?

We use the whole Seam/JE5 stack here in a production real-time trading system. We use many Seam / EJB3 features including Conversations, Extended Persistence Contexts, Seam Remoting, RichFaces, etc.

• Learning curve - Similar to other technology stacks, especially for anyone who has some J2EE experience. Seam has a very logical design and that helps keep the learning curve down.
• Performance - Like any powerful framework, you can make performance mistakes. Seam has reasonable performance out of the box, and if you avoid pitfalls you can get very high performance from Seam/Hibernate/JBoss. Our system uses Seam Remoting to provide real time market information to our customers. Over 1 million AJAX requests per day on modest clustered hardware.
• Features - Seam gets rid of most 'data transfer objects' and other 'adapter' code. We write less framework code, so we can focus on business features. Conversations and extended persistence contexts are easy to use and make users happy because the app behaves like they think it should.
• Future - I chose Seam because it integrates existing standards rather than trying to be it's own standard. WebBeans is the next step in the evolution of Java Enterprise.

I have used plenty of other frameworks. They all have their strengths and weaknesses. I think the main strength of Seam is it's integration with the JE5, structured way of doing things (less dynamic binding, more static binding), which is my preference for larger, more complex applications.

lucius yu wrote on Mar 26, 2009 07:25:
I used .NET in 2001 during it's BETA stage and I was impressed then.

I used Apple WebObject in 2000 during it's transition to Java and I was impressed then. ;-)

That was before my professional life. My first job was a JAVA web developer and boy was I disappointed at how crappy JAVA web development was.

I felt the same, but for both Java and .NET development (when compared to WebObjects)

At that time 2002, the JSF specs just came about and at first glance I thought we finally have something comparable to ASP.NET, but nope... it was until 2009 that JAVA web finally caught up to how .NET WAS back in 2001. I'm guessing .NET has improved a whole lot the past 8 years so filling in the gap, I think we're still way behind. That explains why there are so many companies adopting .NET these days.

I felt the same way about JSF, and about ASP.NET 1.x, ASP.NET 2.x...

I've been contemplating the past few days about investing my time in seam. I have used it on a project in 2006 and I really liked it.

I like it too... it is the best opensource frameworks I have used so far (but I still miss WebObjects, Seam is the closes thing to webobjects I have used, but lately I have been tempted by AribaWeb)

I think it would be something I'd invest more time in just for fun if I had extra time, but professionally I think it might not be worth it at this time only because no companies out there are adopting it. Although, I seriously don't think the learning curve is as steep as people here say it is and I seriously don't find spring better with all the XML crapfiguration.

Well, I believe Seam still has too much XML crapfiguration inherited from JSF.

Could it be because most people are not accustomed to the component based way of thinking yet?

Maybe, in fact, even Seam is not as componentized as it could be, maybe it is because JSF 1.x is not componentized enough (just compare it to Wicket, Tapestry, AribaWeb, or even JSF 2.0 ), and do not even get my started with the XML/String based navigation... why we can not have an object oriented navigation API?

Well in our company,we liked SEAM so much that all of our applications/products are now moved to Seam from different frameworks and our applications are deployed at clients with the SEAM framework only.

We have an application deployed that is used by around 1,000 users, we made conversations as small as possible, we avoid passing anything other than core parameters around in pages.xml, and we use our own entity query with parameters in the page itself (you can read why at my blog linked below). Oh, and we use Richfaces.

Regarding the question of Seam alternatives :

Since implementing things with Seam, I have had doubts, and re-looked at alternatives from PHP, .net, Spring MVC and webflow, non-Seam JSF and even plain old servlets. I wanted to try and find an easier way with something more mainstream, something that had jobs in the 3 or 4 digits range. However, at the end of the day, I ended up coming back to Seam. It's just so easy to use and be productive in if you want to write good OOP systems using a nice stateful framework.

.net - JSF data binding rocks compared to ASP.net, good luck getting started with entities and hibernate and trying to hook controls to entities, and then throwing pagination in the mix. It can be done, it's just ugly.

PHP and Servlets - It's like assembler for the web, not that Assembler is bad (I used to code for the 68K and Z80), but you don't want to go writing anything really complex in it. Coding a single paginated search page with multiple parameters feels like a whole project in itself. In Seam it would take about 5 minutes. It'll also sort out how to handle queries with empty criteria.

Spring MVC and Spring Web Flow - Spring MVC doesn't bring too much to the table other than organizing your pages, the code behind them and doing some form binding. You still end up doing a lot of the manual stuff as in PHP and servlets. However, with Web Flow, it really comes up to par with Seam in a number of ways. JSF and Spring Web Flow is a good combo and in some way it improves upon Seam. However, it also has a number of glitches (as does Seam). Why didn't we go with SWF over Seam? Well, it's close, but Seam feels more like a completely integrated package. Spring stuff is built so you can interchange the pieces, which means that integration is dependent on the lowest common denominator which is the interface expected to be implemented by the pieces.

Ultimately, we stuck with JSF and Seam since there was far more to be lost than gaine by moving away from Seam. Could we have implemented it in other frameworks. Sure, but it would have been a lot more hassle. As an ex-Borland Delphi user, using a less popular, but far superior toolset is familiar territory

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 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?

This is a recent post of Pete Muir about the Seam 2.x support and WebBeans/Seam 3, it seems like there is space for a 2.1.2 and a 2.2 release so there is also space for optimizations:

http://in.relation.to/Bloggers/TheStateOfSeam

I also think the documentation to explain how to make things work faster is very important (like the Dan Allen's article Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude) and they have to push it.

Demetrio

Not even is there an advance training, but the Seam Essentials course suck hard and is really really really outdated.

I have asked JBoss if they will come with an update to the Seam course, but I haven't gotten a positive answer.

Dice.com might not lie but actually if you compare the following Java web frameworks (Seam, Spring MVC,grails,wicket,struts 2) you will see that Seam is quite well ranked on jobtrends.

Also, now add struts and JSF to the Comparison. You will now see that JSF is massively asked by recruiters. If WebBeans (jsr-299) along with JSF 2.0 are part of JavaEE 6, and Seam becomes a RI of jsr-299, it could boost Seam's adoption.

On a side note, Java landscape has a lot of innovative frameworks and Seam is definitely one of them, it pushes integration quite far. But i also have to admit that Java web market is also too fragmented for recruiters... So i think that sticking to the standards is a smart move.

Luc Dew wrote on Apr 05, 2009 05:03:
Dice.com might not lie but actually if you compare the following Java web frameworks (Seam, Spring MVC,grails,wicket,struts 2) you will see that Seam is quite well ranked on jobtrends.

yes...seam is quite well ranked, but try this:

jobtrends

I think that agile and RAD system in the next month/year will have another big boots, mainly due to the economic crisis.

I saw Rod Johnson post one of those indeed.com graphs on one of his blogs a while back.

This is the correct comparison on indeed.com, I'd say...

My Link

params: seam, spring, rails, struts, jsf

forgot to mention for my above post, seam is crushed (again).

here is the official post by Rod Johnson regarding Spring and jobtrends, etc.

Job listings are a good indicator of the true adoption of technologies. They indicate whether or not companies are spending money, making it possible to distinguish substance from hype; they indicate the importance for developers of gaining and growing the relevant skills (an important element of technology perpetuation); and they provide a good guide to the safety for companies in adopting a particular technology.

My Link

I know the Seam devs won't like that, but let's try to be impartial, it's all open-source after all... :)

whether you like the man or not, he's pretty much a genius (with a musicology degree!) and now on the JCP executive committe:

My Link

On a bright note, Seam wins when compared to Erlang and Scala!

My Link

This lack of adoption may also explain the need/push for Web Beans. As Guice and Seam are the two main programming models for JSR299, perhaps Seam 3 (whose core will be Web Beans AFAIK) will be more adopted in JEE shops in the future than prior versions. It helps to be standardized as a JSR obviously.

But Spring is not and may never be but it obviously has a very high adoption rate. Supposedly due to its high productivity compared to pre-EE 5 J2EE.

But lots of AOP translates to lots of XML (and maybe now annotations according to Johnson) and I've heard GKing doesn't believe there really is a whole lot of need for AOP in JEE...

No it's clearly not a fair comparison of Java web frameworks. I have used Spring in many different contexts other than web development. I have also used Spring with raw JSF applications (managed beans directly as Spring beans, or Spring beans as managed beans properties) and Spring with Seam. With Spring core alone you don't develop web applications, you'd need Spring MVC.

You have also added rails which is not Java based (not totally true thanks to JRuby but i guess that rails with jruby is insignificant).

Seam alone falls short compared to php, rails, Asp.Net but we are not comparing the same things. php is a language, i could also have biased results comparing Seam to Symfony (php mvc framework). Asp.Net equivalent in Java is JSF (and JSF based frameworks like Seam), Asp.Net MVC equivalent would be Struts,Struts 2,Spring MVC,grails (any action based web framework).

(1) 2005-2007 - Spring usage by Java world was overwhelming because of EJB2 failure

(2) 2008-2009 - Spring got tough compitition with JEE5 Java world realized the simplicity of EJB3.0

(3) 2009 - JSR-299 WebBeans is JEE6 standard now - JEE6 release in Sep-2009 - Seam3.0 release in Aug-2009 (influenced by JSR-299 WebBeans and Googel Guice) - Spring3.0 release in Sep-2009 (greatly influenced by JEE6 and Seam)

The technologies has changed with time and so as the industry view towards RIA and REA, SOA, REST Webservice, SaaS, Cloud Computing etc..

Now, it would be really interesting to compare Spring with Seam