One gap that Seam should fill in
Posted August 20, 2007on:
We’ve all heard how good Seam is as an application framework, but not many people are aware of the missing gap that Seam hasn’t been able to fill in (at least for the time being). Now this is not a writing to bash on Seam, absolutely not. So if you think this is a Seam-basher article, you’ve got yourself wrong dude. I’m trying to address one feature that Seam should have to make Seam as the best application framework.
Ok enough about the talk, let’s find out what missing gap I am talking about. Many of us already know that Seam provides a tight integration between the JSF managed bean and EJB3 Session Bean so you can use your EJB 3 SLSB/SFSB as JSF action listener. But as time moves on, Seam also provides a business layer and JSF listener as a plain POJO instead of EJB3 SLSB/SFSB. Now this is good news for the community, because if you use EJB3 for your JSF listener, you can not deploy your Seam apps on your existing J2EE 1.4 appserver and less or even Tomcat. Even if you deploy your Seam apps that uses EJB3 Session Bean as JSF action listener on JEE5 compliant appserver you still will face problems as some JEE5 appserver must define the ejb-ref on your web.xml. But really this is a problem more on the appserver side instead of Seam.
Now the problem with using plain POJO on your Seam apps as the business layer is that currently Seam only provides Hibernate as the persistence provider underneath it (isn’t it obvious?). Is this good? No it’s not. What’s the point on using JPA if you can only plug one specific implementation underneath it? The point on using JPA as your persistence layer is that your apps will be compatible with any JPA implementation and not tightly coupled with specific implementation. The problem you will face is that if you deploy your Seam apps on JEE5 compliant appserver other than JBoss, because they don’t use Hibernate as the JPA implementation. So the solution to this is you will have to bundle all the Hibernate dependencies in you apps. For some people this might not be a problem, for some it is, because what’s the point having two libraries that has the same functionality (because as I said before, if your code matched against the JPA spec it should work under any JPA implementation). Now I already have a JPA library from my JEE5 compliant appserver, why should I bundle JPA library too in my apps? Plus, it will make my application file size bigger than it should be.
Actually this is not really the problem because Seam currently already provides PersistenceProvider as an abstraction layer that can be extended and write specific JPA implementation code on it. But currently Seam only has HibernatePersistenceProvider, so if you plan to use persistence provider other than Hibernate, you must create your own class that extends the PersistenceProvider class. Now that’s the problem if you don’t know how to do it/create the class. This current approach will be a solution in the future for plugging in other persistence provider for your Seam apps once Seam already provides classes that extend PersistenceProvider other than HibernatePersistenceProvider. But this approach IMHO is still not good enough because with this way you must have more than one
persistence-unit configuration in your persistence.xml if you plan to deploy your apps on several different JEE5 compliant appserver. Seam should have an abstraction for JPA and no matter what JPA implementation is used underneath it (like the other competing framework has done) and my Seam apps should still work and only requires small amount of configuration changes.
If the PersistenceProvider is to be an abstraction layer for other persistence provider:
- It should not have any specific persistence provider method such as the enableFilter() since there’s no other persistence provider that has Filter other than Hibernate.
- It shouldn’t have genericDependencies to ManagedPersistenceContext as this should be written in the extended class only.
- It should be an abstract class as this class is never called directly, but it is the extended class that is called directly. By the way, it’s an abstraction right? Shouldn’t it be abstract?
I know that this should not only addressed for Seam, because some of it is because of the JPA spec itself being partially complete at some major area. JPA spec still have some missing parts and that way this missing parts is implemented by each persistence provider. And this implementation is implemented differently by each persistence provider. But at this year’s JavaOne, Linda said that this missing parts will be fixed in the next version of JPA. My hope is that Seam developer can work more closely with other JPA implementation developer besides working close with the JCP so Seam could fill in this missing gap to make Seam as a plug and play JEE5 application framework. Despite all that, I really appreciate all the hard work the Seam developers has put into this project. You guys have done a great job.