New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

JBoss Releases Seam 2.0 with Groovy Support and JSF Enhancements

| by Scott Delap on Nov 05, 2007. Estimated reading time: 5 minutes |
Today the JBoss Seam team released Seam 2.0. This comes 8 month after the last major release. Among the top features that project member Norman Richards lists:
  • 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.

King was next asked about JSF components versus moving the entire presentation tier to the browser with something like ExtJS:

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.

InfoQ then asked about the new WebBeans JSR:

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

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

typesafety by Gavin King

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.

Hmmm, I guess I should qualify this by saying that we can achieve some of the advantages of typesafety through tooling. Of course it would be best if Java could be used to define a typesafe, declarative DSL for building user interfaces (think something along the lines of JavaFX, but for the web). However, we're reproducing some of the nice features of a typesafe language (validation, autocompletion, code navigation) in JBoss Tools. In practice, this is really nice.

Re: typesafety by Mark Proctor

MVEL has a mode to provide full type safety, via inference - static typing is also allowed.

It also handles primtives, primtive object wrappers and BigInteger/BigDecimal with full coercion. So you can do mixed maths with all the three.

It has support for inlined maps, arrays and lists. Which can be combined using the 'with' keyword to provide deep graph notation for complex structures. This can allow you to define a single statement to create a complex object hierarchy.

The macro stuff is pretty cool, and can be combined with it's interceptor model for some interesting custom DSLs.

It has the fastest lightwight interpretor around, no additional deps.

You even get a powerful templating language included, to boot.

Mike is working on EL compatability, or atleast a pre-processor. But the work is slow as it doesn't bring anything new to MVEL, so it's less interesting to him, he also hasn't had a strong request for it, from his existing user base.

I know I've harped on about this before, but if you want a small lightweight scripting language with type safety, nothing beats MVEL.

Mark The Drools Blog

Re: typesafety by Gavin King

Yeah, but do you really think that kind of code is appropriate to embed in XHTML attribute values?

I only have one problem with Seam 2... by Simon Pink

And that is that I just rolled out a seam 1.x project - we went live yesterday : ).

In all seriousness, well done and thanks to everyone involved. I love Seam, and I look forward to playing with Seam 2 for my next project.

Congratulation by Hussein Baghdadi

Congratulation for all JBoss Seam developers and thanks for this great tool.
Waiting for a better documentation (well, I'm greed).

Oracle AS+ Seam? by Joost de Vries

Sounds very good.

Regarding new features: Does Seam 2.0 work on the current Oracle AS (10.1.3)?
The previous version did not so we had to go with Spring Webflow.

Re: Congratulation by David Binder

About that documentation issue the reference doc is not that bad and even though it could be better it's almost one of the biggest I've seen among all the framework I've used. What is really poor is the javadoc.

Re: typesafety by Mark Proctor

Mike Brock, from the JBoss ESB team and the MVEL author, has asked me to post this reply on his behalf, as the InfoQ registration system seems b0rked:

MVEL has optional type safety and an API for binding variable types to the compiler is eminently available and documented.

Yes I think MVEL is a appropriate for parsing expressions embedded in XHTML. In fact, the entire purpose of MVEL from the get-go was to parse expressions embedded in JSP and XML documents.

The performance of the runtime was tuned to parse many tiny expressions very efficiently. In fact, MVELs lightweight template parser, built on top of the MVEL core, shows superior performance to Velocity and FreeMarker in it's evaluation speeds. I can even go into it further. MVEL's expressions are evaluated without a session or a context, which makes using MVEL for embedded expressions even more ideal, because of the lack of need for factory caching, etc.

I read your blog post about the fact you think MVEL (like OGNL) has too may language features. For a lot of stuff I agree with you. In fact, that is why we implemented a language capability API that allows you to set the capability level of the parser to restrict what MVEL can do in a particular application. For example: for embedding, you probably don't want code blocks and high-level control flow language extensions available for embedding into small expressions. Therefore, you can lower MVELs language capability level to a level that only permits property, boolean and ternary expressions.

Also MVEL already has break point debug capabilities built in (which EL doesn't), as used by the Drools project in Eclipse - if you ever feel you need to build debug capabilities into your stuff.

Re: typesafety by Alex Popescu

Mark can you please ask Mike to privately email me to solve his registration problem? Thanks,

.w( the_mindstorm )p.
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder

Re: Oracle AS+ Seam? by Pete Muir

Yes, you can use Seam 2 with OC4J; you won't get the full JEE 5 feature set but you can use JPA + Hibernate + Seam POJOs. Take a look at - we're going to integrate this into both the Seam documentation and JPA example for a upcoming patch release of Seam 2.0:

Re: Oracle AS+ Seam? by Jason Lee

Hey, Pete, you beat me to the punch! :)

I haven't forgotten about those issues. I hope to get to those soon.

Re: Oracle AS+ Seam? by Pete Muir

Jason, that would be great. Your blog is a great resource, but having it in the Seam docs makes it more accessible :-)

Tutorial: Achieve Rapid Application Development with Seam+Eclipse+Tomcat by TechieExchange TechieExchange

Thanks to Seam team for 2.0.0 GA release.

I wrote a step-by-step screencast tutorial to make Seam development as RAD - Rapid Application Development with Eclipse and Tomcat, focussing on developer productivity.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you