- 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:King was next asked about JSF components versus moving the entire presentation tier to the browser with something like ExtJS:(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:InfoQ then asked about the new WebBeans JSR:(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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
Community comments
typesafety
by Gavin King,
Re: typesafety
by Mark Proctor,
Re: typesafety
by Gavin King,
Re: typesafety
by Mark Proctor,
Re: typesafety
by Alex Popescu,
I only have one problem with Seam 2...
by Simon Pink,
Congratulation
by Hussein Baghdadi,
Re: Congratulation
by David Binder,
Oracle AS+ Seam?
by Joost de Vries,
Re: Oracle AS+ Seam?
by Pete Muir,
Re: Oracle AS+ Seam?
by Jason Lee,
Re: Oracle AS+ Seam?
by Pete Muir,
Tutorial: Achieve Rapid Application Development with Seam+Eclipse+Tomcat
by TechieExchange TechieExchange,
typesafety
by Gavin King,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
blog.athico.com The Drools Blog
Re: typesafety
by Gavin King,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mark can you please ask Mike to privately email me to solve his registration problem? Thanks,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Re: Oracle AS+ Seam?
by Pete Muir,
Your message is awaiting moderation. Thank you for participating in the discussion.
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 blogs.steeplesoft.com/2007/10/17/seam-and-jpa-h... - we're going to integrate this into both the Seam documentation and JPA example for a upcoming patch release of Seam 2.0:
jira.jboss.com/jira/browse/JBSEAM-2123
jira.jboss.com/jira/browse/JBSEAM-2122
Re: Oracle AS+ Seam?
by Jason Lee,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi,
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.
techieexchange.wordpress.com/2007/11/11/rad-sea...