Seam 2.0 is here

Attention, Seam application framework fans. Gavin King has announced the release of Seam 2.0 beta (TSS discussion). Seam 2.0 brings a lot of changes, as the following list shows.

• Seam WS allows Seam components to function as Web Service endpoints
• Seam components may now be writted in Groovy
• The Seam core is now independent of JSF
• Experimental support for the Google Web Toolkit
• Integration of Hibernate Search
• Introduction of JBoss EL, an extension to the Unified EL of Java EE 5
• Major enhancements to Seam Asynchronicity, including Quartz integration
• Major enhancements to jBPM integration
• Completely reorganized packaging of built-in components
• Migration to JSF 1.2
• Simplified configuration
• Support for pageflow composition
• Enhancements to the integration testing framework
• New transaction abstraction layer with support for non-JTA environments
• Enhanced JavaDoc
• Two new example applications
• Migration to the new Embedded JBoss
• Seam JSF controls reimplemented using Ajax4JSF CDK
• Many, many bugfixes

If you look through these new features, read between the lines and know a little of Seam's history, something is bound to occur to you. Once upon a time, Gavin King began writing Seam partly to show that EJB 3.0 was usable. Seam was supposed to demonstrate how far EJB technology had come and that it was ready for everyday use.

As the Seam community grew, things took a turn. Little by little, features were added to Seam that bypassed parts of EJB. Users want good old Tomcat and do not necessarily want a full-fledged application server. In version 2.0, Seam even dropped the idea of embedding JBoss inside Tomcat, a bizarre idea in itself.

Version 2.0 has its own abstraction over the transaction API so that Seam applications can run outside a JTA environment. The Quartz scheduler was added for asynchronous processing. These changes suggest that the J2EE stack is a lot for most developers to take on and that they prefer lighter solutions that run primarily in Tomcat.

The question is why the J2EE stack, or an application server, is so much to take on. Hosting may be a factor, as might more complicated development, from configuring the server to dealing with unfamiliar technologies behind it, or the higher demands of robust application servers overall in areas such as memory and application deployment speed.