benno buesch wrote on Mar 26, 2009 11:27:


when developing with jsf, i can really see no alternative to using SEAM; all these features SEAM adds without sacrificing performance is just great!

but now we are in a new project and use wicket as the web layer, and now i am unsure if we should use SEAM  together with wicket. http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/

1. comment-13494 raises a similar question.

I found that comparison to be less than useful.  This is apples and oranges.  Sure, you can manage an extended persistence context by yourself, or implement OSiV with Spring, or whatever.  Take your pick.  Seam does a number of things well, and WebBeans (which Seam will augment) does them even better.  It's just a question of leveraging the work of others, and taking on the dependencies you get as a result of that.

I think your list is pretty much correct except for:

contexts:
conversation and page scope are not yet integrated (as page scope depends on the jsf lifecycle and conversation id's must be integrated in all linking/posting components)

The conversation scope is implemented.  In the released version, it is propogated through a request filter that appends the conversation id.  In the unreleased code in SVN, it's implemented with Wicket Page metadata.

The page scope is IMHO less than useful in JSF land (note that it doesn't exist in Web Beans, though it may in Seam's extensions to Web Beans, I haven't heard.)  I've built a lot of Seam/JSF code and hardly ever used the PAGE scope.  But it's even less useful in wicket, because you essentially have a page scope through the use of models, which are tied to a page and used as long as the page is not expired.

That having been said, if you want the page scope, provide a patch in a JIRA, and I'll add it.  It does provide a uniform way to approach contexts, but it's not very wicket-y.  My approach in the seam/wicket integration has been to use Seam for the things that Wicket doesn't have built-in support for, and to prefer Wicket's approach for things that are really tied to the presentation tier.    That's why, for example, I haven't implemented anything similar to pages.xml for wicket.  Wicket has its own way of handling navigation (which is strongly typed, where pages.xml isn't.)

This entire conversation really needs to take into account WebBeans.  The web beans release will support Wicket, and then we have to see what Seam looks like when it's reimplemented as a set of services on top of Web Beans, i.e. binding annotations and some interceptors. 

Clint,

Doesn't the thought of this reinvention of Seam on top of WebBeans scare you?  It's almost as if Seam was used as a catalyst to promote WebBeans, and now those who are bound to Seam are going to have to completely re architect their application in the future.

You can even look at Seam in JIRA and find that there are is only one major update planned until 3.0 (WebBeans).  I'm sure this will change as bugs are found or features are requested, but still...

Have we simply fallen into a trap bait and sinker?

Also, the commotion on this forum just keeps getting worse and topics are becoming more and more basic.  This shows that more and more people are attempting to adopt Seam, but where is the serious, hardcore conversation?  For those of us with difficult problems or more pragmatic questions there are few avenues towards which to turn.

Occam's Razor gives the correct explanation here.  There wasn't a grand conspiracy to bait people with Seam and then hook them into using WebBeans.  I hardly see how the only company funding Seam development (Jboss) would benefit by that in any case.

The real explanation is that Seam was created, evolved, and its creators have decided upon the essential parts of Seam that really fit well into a JSR spec, i.e. the parts that are particular novel and represent additions to the JavaEE platform that aren't really addressed already, primarily type-safe dependency injection,  contextual components (and the formalization of the conversation scope for jsf), annotation-based type-safe interceptors, aggregation of new interception/deployment/context/naming types (through stereotypes), and a way to do all of this for POJOs as well as EJBs without compile time byteweaving or excessive xml.  These things are being formalized, specified, and implemented to that specification.  The parts of seam that correspond with this will be re-implemented using this API, and the parts that go above and beyond (e.g. security, jBPM as a context, etc.) will be implemented as extensions using the hooks that Web Beans provides. 

In addition, if you've looked at the two source bases, and/or played with both, you'll see that a lot has been learned, and WebBeans is a big jump forward in terms of consistency.

So no, I'm not scared or frustrated.  This is the way things work, technologies evolve.  I assume that the Seam team will make a big effort to preserve as much backward compatibility as possible for Seam 2.X users as the transition is made to Seam 3.X.

As far as the level of conversation on the forum, I am frustrated by that, but I can only do what I can as an individual: take part in good conversations when I see them.  What's more, I think 99% of the conversations that could be construed as pollution are really confusion due to the problematic designs inherent in JSF 1.X, the bugs in RichFaces, and the complexity of EJBs.  If I actually look for seam-specific problems, I don't see a lot of them.  But then again, I'm not a fan of EJBs/RichFaces/JSF, so that's my snarky preferences coming through :)

Benno, any luck creating stateless pages with seam?  -David