Are there any disadvantages to SEAM?

Question

As a java web applications developer I have used this last year JSF (SUN) for a framework to my web applications. I have to say I quite liked using it, it makes the developing easier.

Recently, I have read a lot of good things about JBoss Seam, but I still haven't encountered a person that has used it. From what I have read it seems that SEAM is the next step of JSF.

My question is therefore, for you that have used SEAM: while you where working with this technology did you encounter any disadvantages? Would you say it felt natural for you working with it?

Answer 1

I like JSF and I evaluated Seam not long ago. JSF is a web UI framework, whereas Seam is a more general web application framework, that integrates not just JSF but conversational contexts, workflow (jBPM) and object persistance (preferably EJB3). I was first attracted to Seam by the advertised auto-generated scaffolding, but I never did get it to work with my enterprise data model. Since then I've grown more interested in Spring Framework and Spring JSF. It appeals to me as being more modular and if you use iBATIS it needs only a servlet container like Tomcat, not a Java EE container like JBoss. Spring has been around longer and has greater mindshare.

Also ICEfaces is great with JSF and facelets, it works perfectly well with or without an application framework like Seam or Spring.

Answer 2

You can always use the Factory annotation to avoid calls to the same method over and over. Factory allows the component to be updated.

Answer 3

If you put logger on your Seam component (Eg. resultList) you will see that Seam calls the same method many times. This is the only annoying thins about Seam. But Seam definitely "fixed" JSF which is pretty messed up by itself. Lets see JSF2. Regardless those problems, I am very happy to use Seam.

Answer 4

I have used Seam in an ongoing largish project with IceFaces. Seam certainly is far better than using plain JSF (refer the link posted by Damo a couple of answers above).

However, some of the issues I remember:

• unit testing: getting SeamTest to work properly especially in a continuous integration build was hard, search the web for "SeamTest issues". Also see this: Has anyone successfully run integration tests with Jboss embedded, Seam and Maven?
• Multiple ways for developers to do things and not too many best practices documented. So you have to spend time and figure out what is best for your project team. For example, when implementing forms, here are the potential tags (note that some of them overlap):

Facelets <ui:repeat>

JSTL <c:forEach>

JSF <h:form>

ICEFaces <ice:selectOneMenu>

JSF <f:selectitems>

Seam <s:button>

• performance is suspect, especially with IceFaces, here is a related article Also, you need "guru level" knowledge of Seam in order to do the Right Thing, the default way lands you in trouble. See this article for details: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude - Part 1
• since Seam 3 is imminent, and supposed to make use of 2 new specs (JSF 2 and WebBeans) that leaves questions on what happens to projects on Seam 2 and how long it will take for things to get stable
• learning curve. IMHO seam tries to do too much, give you wrappers over things like iText, Quartz, JExcel, jBPM, etc. And the Seam integration with third party frameworks is expectedly a step behind the latest versions. For example we had to integrate jBPM directly because we needed some of the latest features.
• maybe because of the lack of criteria queries in JPA 1.X, the way you implement dynamic search screens (where user fills in a lot of filter options and you have to generate dynamic HQL) felt very in-elegant, and this is when using the recommended "Seam Application Framework" EntityQuery class, see the link below for a simple example, but you can get an idea of what to expect for complex filter criteria, handling nulls, order-by and all: How can I to order an EntityQuery query in a seam app?

Answer 5

It feels natural to me and using annotations make life easier. I can't even imagine working with getAttribute/getParameter framework. One disadvantage is that seam-gen doesn't work with Maven yet (but Seam3 will be Maven based). I think Seam makes you focus on what you want to achieve and with other frameworks you have to think how to do it. Have you ever tried to do Ajax with javascript/prototype/jquery? It's really painful compared to seam Ajax button with method call and what to reRender. Javascript is really not needed at all with seam and Rich Faces. for me it's the best framework I've used.

Answer 6

Seam, as a integration framework, really will show its usefulness when paired with other frameworks that you want to use.

If you're going to be using EJB and JSF already, SEAM is killer.

If you're going to be using JSF (plus any of its related tools, like IceFaces or RichFaces) SEAM POJOs can simplify your setup a lot as well as give you access to the life-cycle states that seam provides (conversation, etc.)

If you're using EJB with Wicket or GWT, Seam might be able to save you some configuration as well, though, I've not personally used it in this configuration.

As has been said, Seam's disadvantages are inherent in any abstraction framework: It's hiding the details from you. If it starts to leak, you're in trouble. I've not had it leak on me yet but I also spent the time to give myself a good, basic understanding of how it works. How the EL works with the Seam Annotations and such.

Whether or not you're going to find seam useful depends on the frameworks you're going to use it with. Seam definitely has its sweet spot but that spot is growing. Seam definitely isn't a dead project. :)

Answer 7

It's not correct to say the "Seam is the next step of JSF." Seam doesn't have to use JSF as the view layer. It can also use Wicket or GWT.

However when used with JSF it does a great job of simplifying it. You have less XML config than standard JSF and I often forget that JSF doesn't have things like a conversation context or parameterized method calls in EL. eg:

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>

It's easy to work with and the ability to use POJOs everywhere is very liberating. It's biggest disadvantages are those related to JSF:

• Too much reliance on HTTP POST (which s:button/link doesn't always solve)
• Lots of javascript
• Excessive calls to Getters/Setters
• Nasty looking HTML; etc

There are more than enough pages detailing the shortcomings of JSF elsewhere (note that these aren't criticisms of Seam - rather of JSF1.x and many are resolved in JSF2.0)

I don't believe that Seam is the "next step" for JSF but it and Facelets are crucial if you're planning to use JSF1.x right now.

I think that JSF2.0 and WebBeans are the next step.

Answer 8

The advantage of any framework like SEAM or Grails is that it's a higher level of abstraction. It takes care of underlying details for you and, if it's designed and written well, makes things easier.

The disadvantage of any framework like SEAM or Grails is that it hides a lot of details from you. If you don't ever learn what's going on underneath you can find yourself in a world of trouble if you get stuck and don't know anything about the code that's generated for you.

Another disadvantage is that the assumptions they build into the model might not always be what you want. But changing them means breaking the path that they've laid down for you, which isn't easy.

My advice would be to use the framework and appreciate the advantages it brings, but don't use them as an excuse to stop learning what's happening underneath. Be the person who could write the whole thing by hand, without the framework, but chooses to use it for the leverage it provides.