JBoss Releases Seam 2.0 with Groovy Support and JSF Enhancements

• WebServices - Web services can be conversational and can make use of Seam components and services.
• Groovy - Seam components can be written in Groovy
• Hot Deploy - In development mode, Seam can hot-deploy component definitions without needing to redeploy your entire WAR or EAR.
• Eclipse Support - Seam 2 support in JBossTools is being completed with project wizards, integrated tested, autocomplete on EL, visual editing of view pages, and more.
• Not Dependent on JSF - Seam has now been de-coupled from JSF so that it can be more easily used with other web frameworks. Experimental GWT integration has been prototyped that shows how this might work.
• JSF 1.2 Support - Seam has switched from myfaces to the JSF RI as its default JSF implementation.
• JBoss EL - Seam offers JBoss EL support with parameterized bindings, support for non-JavaBean properties and projection.
• Maven - Seam own dependencies are managed in Maven. A Maven repository for Seam is also available.
• Integration - Integrations are available for popular projects such as Quartz, JFreeChart, Hibernate Search, and iText

InfoQ caught up with project lead Gavin King to discuss the new release. InfoQ first asked what was the most important thing learned with 1.0 that made 2.0 a better framework:

I think the biggest mistakes I made on 1.0 were:

(1) Going ahead and developing Seam to mostly assume an environment with JSF, EJB3 and JTA. These are all very popular technologies, no doubt, but there have still been a lot of people who've wanted to use Seam in other environments, and they've pushed us to "open up" the implementation.

(2) Not realizing just how big our built-in component library was going to grow. On the early versions, I just naively threw all the built-in components into org.jboss.seam.core. In Seam2 we had to completely reorganize the packaging structure.

Well, I think there's two major thing to consider here:

(1) Do you prefer to define the user interface declaratively, or programmatically?

(2) Exactly how much functionality can really *execute* on the client side?

There's also the question of how typesafe you want to be.

These questions are almost orthogonal. For example, GWT gives you a typesafe, programmatic, client-side approach. On the other hand, Wicket gives you a typesafe, programmatic, server-side approach.

JSF gives you a somewhat typesafe, declarative, server-side approach, with the option of working in programmatic mode when you need it. Each approach has its advantages and disadvantages, or course, but here's why I think the JSF approach is compelling:

First, I much prefer to define the user interface in a declarative language. The user interface is by nature hierarchical, and I want the structure of my code to reflect that. I've simply never felt comfortable creating a user interface using swing-style code. This kind of code always looks ugly and is difficult to maintain - it's a bit like Java code that parses XML by walking the DOM tree. There's a fundamental structural disconnect there.

Sure, for very dynamic parts of the user interface, programmatic manipulation is useful. But, this is certainly the uncommon case. Most user interfaces are extremely static except at the level of individual controls. And JSF helps you even in this uncommon case, since it lets you directly manipulate the JSF component tree in Java code. And of course, you can always fall back to writing JavaScript code that works with the browser's DOM. (One of these days, someone will create a JSF implementation that enables client side access to the JSF component tree, but we're not there yet.)

Second, I simply don't buy into the idea that keeping more state and performing more application logic on the client side is going to save a lot of development effort. There's simply too many central concerns that can only be effectively dealt with on the server side: persistence, security, data-level concurrency, etc. What ends up happening if you try to bring your application code to the client side is that you end up right back where we were three or four years ago, with an architecture that features a stateless service layer, data transfer objects, fine-grained manual fetching of data and merging of changes. This is the painful programming model we just escaped by adopting stateful components and conversation-scoped persistence contexts - all server-side technology.

With RichFaces and Seam, you can create user interfaces that fetch data asynchronously, update the view interactively, respond to user interaction asynchronously and apply changes interactively, all in a well-defined optimistic transaction, without all that extra noisy boilerplate. Sure, it takes a bit more effort to learn JSF and RichFaces than some other approaches, but it will pay off in the long run.

The biggest downside I see with the basic approach of JSF today is rarely commented upon: the lack of typesafety in the use of EL to bind the view to the model. My ideal environment would be one which supported a truly typesafe declarative language for defining the user interface. Unfortunately, Java has no real support for creating such DSLs. Pity.

Web Beans features many ideas that came from Seam:

• contextual components
• conversations
• component overriding via "precedence" rules
• "deep" integration with Java EE
• binding-annotation-based interceptor bindings
• event notifications

On the other hand, it also stole the idea of binding-annotation-based dependency injection from Guice, and this had some far-reaching consequences.

Web Beans mixes all these ideas together into a very unique programming model that emphasizes "loose coupling with strong typing". You can achieve a very loosely coupled application by taking advantage of:

• contextual lifecycle management (stateful components interact as if they were services) to decouple client and server lifecycles
• deployment time component overriding to decouple client and server implementations
• event notification to decouple message producer from consumer
• interceptors to decouple crosscutting (technical) concerns

all without sacrificing typesafety. Everything is done via typesafe annotations - there's no strings, hiding under the covers, waiting to bite you at runtime :-)

In sum, Web Beans builds on the tradition of Seam, but I believe it's an even more compelling model. I'm blessed with a great expert group :-)

Finally King was asked about if using Seam to develop the new wiki running in.relation.to had caused the team to find any holes in the framework:

We spotted a few bugs and minor limitations. But the biggest influence the Wiki is having is in motivating us to develop a plugin architecture for Seam. By "plugin", we mean something a bit like a portlet, except for not sucking.