Building Spring-Seam Hybrid Components For Web Applications
- Share
-
- |
Read later
Reading List
Spring and JBoss Seam frameworks provide different set of features for developing enterprise web applications. Spring is a JavaEE middleware framework, built on features like POJO Abstraction, Dependency Injection(DI) and Aspect Oriented Programming (AOP), which provides integration with frameworks like Hibernate, TopLink and iBatis. Seam is a web application framework that integrates technologies such as AJAX, Java Server Faces (JSF), Enterprise Java Beans (EJB3), Java Portlets and Business Process Management (BPM). Is it possible and does it make sense to use these two frameworks together in developing web applications? This topic was the main focus of a recent article and a java community forum discussion with emphasis on how the strengths of each of these frameworks can be used together to get best of both worlds.
Dan Allen recently wrote two articles about integrating Spring and Seam frameworks in web applications. In the first article, he explained how to build hybrid components that benefit from both Seam and Spring container functionality. He said that Seam unifies JSF, JPA, EJB 3 and other technologies but it doesn't support some of the features Spring offers out of the box, such as lightweight remoting, AOP declarations, framework template classes and resource injections. This is where building a Spring-Seam hybrid component, a managed object that benefits from functionality provided by both the Seam and Spring containers, comes into picture. Seam provides a module for integrating Spring Framework into the web application as well as share application components and low-level resources.
Using a sample web application, the author explained how to integrate Spring beans into a Seam application by using the ContextLoader
In part 2 of the article series, he talked about adding stateful behavior to Spring beans, which is still a challenge to accomplish when using Spring framework alone. Spring beans can be infused with "State" by registering a Seam custom scope handler that allows Spring beans to be stored in Seam contexts to make the temporary conversation (for implementing the redirect-after-post pattern), long-running conversation (for single-user page flows), and business process scopes to support interactions from multiple users over an extended period of time. This way, the Spring beans can be stateful without having to resort to the HTTP session.
The author discussed the scope issues and thread-safety problems at run-time when using Spring and Seam together. Spring injects dependencies once at creation time, whereas Seam performs injection dynamically, before every method invocation. This difference in the design philosophy of these two frameworks can lead to "scope impedance" paradox where a bean outlives its intended lifetime as a result of attaching itself to a longer-lived component. This situation occurs when using Spring's static dependency injection to wire components with different scopes. Seam offers a solution to help avoid both scope impedance and thread-safety problems. Instead of injecting a bean instance directly using a "ref" element, you inject a proxy using the seam:instance tag.
There has also been interesting discussion on this topic in the community forums. Rick Hightower gave an overview of Seam 2.0.1 features and led a discussion thread on using Seam and Spring together. Some of the questions that have been asked in the discussion are:
- If you are using Seam and Spring, and you had to live without one of them, which one would it be?
- Do you use Seam with or without EJB3?
- Do you use Seam with or without Spring?
- How good are the Seam generation tools?
- Is Seam the best way to write a JPA and JSF based application?
- Where do you think Spring and Seam overlap and when they do overlap which one is better?
Spring version 2.5.4 and Seam 2.0.1 GA were released recently. For more InfoQ news on these two frameworks, see Spring and Seam sections on the website.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login 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
Community comments
We've choosen JBoss Seam
by
Marcin Niebudek
Posted
Re: We've choosen JBoss Seam
by
Dan Allen
Posted
Re: We've choosen JBoss Seam
by
Dan Allen
Posted
Spring + JSF
by
Jeremy Grelle
Posted
Re: Spring + JSF
by
Dan Allen
Posted
We're using both!
by
Flavio Medeiros
Posted
We've choosen JBoss Seam
by
Marcin Niebudek
When we started developing tinyPM, our light agile management tool, we decided to use Spring 2.0 with Hibernate and JSF. I really like the JSF + Facelets (especially the latter) as the view layer. Quickly we've notices that we should also start using Spring Web Flow and it's JSF integration code. Unfortunately SWF support for JSF was in a very alpha stage few months ago. We were strugling with Spring + JSF for over 2 months and then decided to switch into JBoss Seam (ver. 1.2 back then).
I must admit that maybe Spring gives you a bigger freedom but we've choosen the stack already (JSF, JPA with Hibernate) and the JBoss Seam framework suits this the best. I love the event/observer model in Seam, I really appreciate the custom Seam tags that solve many small but very common problems when using JSF. I like JBoss Seam scopes (although sometimes they are tricky and not so well documented, so it took as a little more time to fully understand how they work along with the Seam's DI). The security model in Seam is very nice and easy to use. Finally I really prefer annotations over XML configuration. Oh I've forgot about extended EL - it's great.
There are also some drawbacks. There is almost no AOP support, especially when you try to develop an application using POJO and deploy it into non JavaEE server like Tomcat (as we do with tinyPM). I miss the Spring's ease of externalizing configuration of all resources. I also sometimes have a filling that Seam is too bit tricky and Spring is more predictable, but this is just a matter of learning curve Seam have (especially before ver. 2.0 when the docs were not to helpful).
I think the RichFaces and A4J libraries are still very unstable and make JSF pages very heavy, so we're looking for ways to get rid of them from our preferred stack. But Seams remoting seems to be very promising in that. The rest we will just do using Prototype and Scriptaculous directly.
So generally Seam framework may be a very productive and light solution for JSF applications. We are currently using 2.0.1 version and it solves a lot of problems you may encounter when trying to do something more then just a PetStore or yet another Hello World app in JSF. Seam will be our framework of choice for the Java web apps for some time.
Regards,
Marcin
I must admit that maybe Spring gives you a bigger freedom but we've choosen the stack already (JSF, JPA with Hibernate) and the JBoss Seam framework suits this the best. I love the event/observer model in Seam, I really appreciate the custom Seam tags that solve many small but very common problems when using JSF. I like JBoss Seam scopes (although sometimes they are tricky and not so well documented, so it took as a little more time to fully understand how they work along with the Seam's DI). The security model in Seam is very nice and easy to use. Finally I really prefer annotations over XML configuration. Oh I've forgot about extended EL - it's great.
There are also some drawbacks. There is almost no AOP support, especially when you try to develop an application using POJO and deploy it into non JavaEE server like Tomcat (as we do with tinyPM). I miss the Spring's ease of externalizing configuration of all resources. I also sometimes have a filling that Seam is too bit tricky and Spring is more predictable, but this is just a matter of learning curve Seam have (especially before ver. 2.0 when the docs were not to helpful).
I think the RichFaces and A4J libraries are still very unstable and make JSF pages very heavy, so we're looking for ways to get rid of them from our preferred stack. But Seams remoting seems to be very promising in that. The rest we will just do using Prototype and Scriptaculous directly.
So generally Seam framework may be a very productive and light solution for JSF applications. We are currently using 2.0.1 version and it solves a lot of problems you may encounter when trying to do something more then just a PetStore or yet another Hello World app in JSF. Seam will be our framework of choice for the Java web apps for some time.
Regards,
Marcin
Re: We've choosen JBoss Seam
by
Dan Allen
It's great to learn about this Seam success story. As you pointed out, if you are committed to JSF, then Seam is a must-have. But, going a step further, Seam actually makes JSF one of the stronger web framework choices overall. tinyPM is certainly proof that the Seam/JSF/JPA+Hibernate stack is a winning combination. You cited that the event/observer pattern in Seam to be one of its best qualities, which I agree doesn't nearly get the attention it deserves. One benefit you didn't mention was how Seam poignantly solves the persistence context management problem that plagues nearly every Spring application written. Whether or not you believe in ORM, you have to admit that Seam gets it right.
As with all things, there is always room for improvement. As you mentioned, the novelty of advanced scoping can make this powerful weapon difficult to wield at first. I spend a lot of time explaining Seam's scopes in Seam in Action and how best to use them. My feeling is that it is worth the effort because these scopes fit more naturally with the business cases being managed by the application.
The AOP support in Seam is intentionally restrictive as a commitment to simplicity. In essence, the AOP support models that of EJB 3, favoring the use of its predecessor if you are developing with session beans. While to some AspectJ and Spring AOP are incredibly powerful, their syntax can be daunting to a newcomer, perhaps requiring the skills of an advanced Java developer even in the maintenance phase of an application. Seam encourages you to develop stereotypes, which are annotations that describe the intended behavior of an object, implemented by an interceptor applied by way of the annotation. If you do need the power of AspectJ or Spring AOP, that is what you have the Spring-Seam integration for. Remember, your Spring beans can behave just like Seam components in all other ways.
As for your experience with RichFaces, I will agree that its strengths are overshadowed greatly by its weaknesses. My feeling is that it needs to enter a stabilization period because there is no question that it has cornered an innovative approach to the Ajax/JSF combination. However, if you have made up your mind to look elsewhere, I encourage you to try ICEFaces. In speaking with their developers, they seem committed to reducing bandwidth and have an eye towards the next generation user interfaces.
As with all things, there is always room for improvement. As you mentioned, the novelty of advanced scoping can make this powerful weapon difficult to wield at first. I spend a lot of time explaining Seam's scopes in Seam in Action and how best to use them. My feeling is that it is worth the effort because these scopes fit more naturally with the business cases being managed by the application.
The AOP support in Seam is intentionally restrictive as a commitment to simplicity. In essence, the AOP support models that of EJB 3, favoring the use of its predecessor if you are developing with session beans. While to some AspectJ and Spring AOP are incredibly powerful, their syntax can be daunting to a newcomer, perhaps requiring the skills of an advanced Java developer even in the maintenance phase of an application. Seam encourages you to develop stereotypes, which are annotations that describe the intended behavior of an object, implemented by an interceptor applied by way of the annotation. If you do need the power of AspectJ or Spring AOP, that is what you have the Spring-Seam integration for. Remember, your Spring beans can behave just like Seam components in all other ways.
As for your experience with RichFaces, I will agree that its strengths are overshadowed greatly by its weaknesses. My feeling is that it needs to enter a stabilization period because there is no question that it has cornered an innovative approach to the Ajax/JSF combination. However, if you have made up your mind to look elsewhere, I encourage you to try ICEFaces. In speaking with their developers, they seem committed to reducing bandwidth and have an eye towards the next generation user interfaces.
Re: We've choosen JBoss Seam
by
Dan Allen
By the way, anyone using Seam in production is encouraged to share their success story on the Seam Wiki:
seamframework.org/Documentation/SeamInProduction
seamframework.org/Documentation/SeamInProduction
Spring + JSF
by
Jeremy Grelle
While I certainly applaud any approach to enhancing the integration between JSF and Spring, and I think it's great to have such advanced Spring integration available in Seam, I would be remiss if I didn't point out the recent final release of Spring Web Flow 2, which includes the Spring Faces module for deep integration between Spring and JSF. We feel that Spring Faces offers a compelling alternative to Seam for Spring users who want to use JSF for the view layer. We re-built Web Flow's JSF integration from the ground up, and while there were some bumps in the road (as Marcin unfortunately seems to have experienced first-hand), the final model is solid and we've been getting some great feedback from our existing community. While Seam unarguably offers power in its own right, there is something to be said for being able to use the Spring programming model natively throughout the stack.
We provide quite a lot of the same benefits of Seam such as fine-grained scope management (including the ability to define Spring beans in these scopes), conversational JPA and Hibernate persistence options, a powerful security model through our integration with Spring Security 2, and a number of conveniences that make it easier to work with JSF constructs such as the DataModel. We provide all of this in a completely portable runtime without the need to swallow EJB3, and with the full power of Spring's AOP support available natively. I firmly believe that the Flow Definition Language, Web Flow's higher-order DSL for declaratively defining controller interactions, leads to a more productive development experience as it can serve as a complete replacement for the JSF managed bean model and navigation model and is fully dynamic and refreshable at runtime. In fact, it today provides a large portion of the features that many believe to be missing from JSF.
So if your answer to, "If you are using Seam and Spring, and you had to live without one of them, which one would it be?" is Spring, and you want to leverage the power of the JSF UI component model but are looking for a better development experience, I highly encourage you to check it out for yourself.
Cheers,
Jeremy Grelle
Spring Faces Lead
We provide quite a lot of the same benefits of Seam such as fine-grained scope management (including the ability to define Spring beans in these scopes), conversational JPA and Hibernate persistence options, a powerful security model through our integration with Spring Security 2, and a number of conveniences that make it easier to work with JSF constructs such as the DataModel. We provide all of this in a completely portable runtime without the need to swallow EJB3, and with the full power of Spring's AOP support available natively. I firmly believe that the Flow Definition Language, Web Flow's higher-order DSL for declaratively defining controller interactions, leads to a more productive development experience as it can serve as a complete replacement for the JSF managed bean model and navigation model and is fully dynamic and refreshable at runtime. In fact, it today provides a large portion of the features that many believe to be missing from JSF.
So if your answer to, "If you are using Seam and Spring, and you had to live without one of them, which one would it be?" is Spring, and you want to leverage the power of the JSF UI component model but are looking for a better development experience, I highly encourage you to check it out for yourself.
Cheers,
Jeremy Grelle
Spring Faces Lead
We're using both!
by
Flavio Medeiros
We're using the power and flexibility of Spring with JBoss Seam powerfull capabilities already listed here. For view we're using the ExtJS framework.
We created a internal framework that encapsulates much of Seam and Spring advanced funcionalities, freeing developers from learning more advanced features of each framework. This framework is in Java and Javscript, for easy use of Seam remoting.
We created a internal framework that encapsulates much of Seam and Spring advanced funcionalities, freeing developers from learning more advanced features of each framework. This framework is in Java and Javscript, for easy use of Seam remoting.
Re: Spring + JSF
by
Dan Allen
I'm very happy to see Spring embracing JSF and improving on it. I think what Seam proved, and what Spring Web Flow validated, is that the JSF life cycle is more extensible than most people gave it credit for at first. These projects have breathed life back into JSF, and frankly, I think it is worth saving.
I had a lot of pain when I first started using JSF and was almost ready to give up on it when Seam came around. While I am sure there are tons of innovative frameworks than can boast productivity in one area, nothing comes anywhere close to giving the full breathe of control as the two frameworks being discussed in this series. To adopt Seam, you definitely do not have to swallow EJB 3. In fact, all you need to make an application functional in Seam is a good old JavaBean with the @Name annotation and one XHTML-based Facelets template. Even the component descriptor is optional. Of course, there are 550 pages of Seam in Action + 150 more pages online worth of additional features to learn about.
One thing I think Seam does right, that perhaps even Spring Web Flow misses, is to honor the EntityManager/Hibernate Session as a first class object in the application. You can begin a conversation just by flipping a switch and that conversation stays on for as many requests as you make until you turn it off. All the while, the persistence context is right there with you (lazy load, no need to merge, application transaction). You don't need to take some prescribed path through the application and there is no Open Session in View hack. Granted, you can use constrained navigation with jPDL, but you will know when you are ready for that.
I could go on and on. But my theme is always the same. Don't let anyone tell you what to use, not even the framework (forced interfaces in Spring and EJB 3). Decide for yourself.
