Joshua Java

One gap that Seam should fill in

Posted on: August 20, 2007

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:

  1. 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.
  2. It shouldn’t have genericDependencies to ManagedPersistenceContext as this should be written in the extended class only.
  3. 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.


13 Responses to "One gap that Seam should fill in"

This is not correct, Seam works with any JPA implementation. One of the example applications demonstrates Seam deployment to GlassFish/TopLink.

Certain features of Seam (atomic extended persistence contexts is the main one) depend upon non-standardized functionality, which is the reason for the existence of the PersistenceProvider interface. If your JPA provider supports this functionality, you can implement a PersistenceProvider for that JPA provider and get the functionality in Seam. But this is certainly not required. The base implementation of PersistenceProvider is sufficient for most people. And it is my expectation that all of the operations on PersistenceProvider will be available in JPA 2.0.

[…] One gap that Seam should fill in We’ve all heard how good Seam is as an application framework, but not many people are aware of the missing gap that […] […]

good entry point to start using Seam

[…] One gap that Seam should fill in We’ve all heard how good Seam is as an application framework, but not many people are aware of the missing gap that […] […]


Interesting. I haven’t used Seam and I don’t intend to. Couple of things come to mind though:

1. What motivates the product design of Seam? JEE5, JPA, EJB3 etc. Seam has all the acronyms needed to achieve JEE corporate sales.

2. If Seam is truly community driven, what is there stopping you fixing this problem and contributing your patch back to Gavin?

JBoss is a software company and Seam is a product, I believe this is the root cause of the problem you describe.

In contrast 37Signals make their money shipping web applications like the rest of us. Rails is not a product and DHH as made it clear that he has no intention of turning it into a product. Take it as is, and extend as you like. The Rails community has responded with plug-ins that address all sorts of issues. So in a sense the community owns Rails. In contrast it is very clear who owns Seam.

Hi Gavin, thanks for stopping by.

Last time I’ve tried using other JPA provider other than Hibernate and it didn’t work simply because they can not find an active transaction. I didn’t use EJB3 as the business layer, I use plain POJO. And if you use plain POJO you must have the entity-transaction component defined in your components.xml, correct? The entity-transaction component will need the managed-persistence-context component, correct? And the managed-persistence-context component will need entity-manager-factory component, correct? I believe the entity-manager-factory component is not compatible with other JPA provider other than Hibernate. Please CMIIW.

Btw, I’ll be waiting for the next revision of JPA 2.0 too. I believe that when JPA 2.0 is done, Seam will provide a better integration with other JPA provider.

If you are using JTA, all you need to do is configure your JPA provider to locate the current JTA transaction according to whatever mechanism is appropriate for the environment you are running in. (All JPA implementations have some app-server-specific setting that is required in non-EE5 environments.)

If you want to use resource-local transactions instead of JTA, you need to specify transaction:entity-transaction in components.xml. And yes, you would also need to specify persistence:managed-persistence-context and persistence:entity-manager-factory to set up a Seam-managed persistence context. These built-in components are not in any way dependent upon Hibernate and will certainly work with any JPA provider.

Thanks for coming back again Gavin,

Not all JPA providers have transaction_manager_lookup unlike Hibernate. Toplink is one of them. And if I use RESOURCE_LOCAL, the joinTransaction() method that is called from ManagedPersistenceContext will make it not working.

TopLink should have something like transaction_manager_lookup. If it doesn’t, then your problem is not Seam, it is that TopLink doesn’t support JTA in J2EE environments. This sounds like an unlikely limitation of TopLink.

Check EntityTransaction.enlist(), it is a no-op, unlike the superclass method which calls joinTransaction(). So if you use transaction:entity-transaction, joinTransaction() will not be called. (At least that is what the code does in the current CVS version, not sure what version of the code you are looking at.)

Of course this is not the problem on Seam, that’s why I hope Seam could fill in this gap. 🙂

I used Seam 2.0Beta1. I’ll wait for the next 2.0CR1 since I can’t connect to CVS from here.

Do you have any example of seam deployment on Tomcat6 and TopLink? I am using Seam pojo and no embedded jboss.


I am also looking for an example on how to deploy a seam application using Hibernate on Tomcat6. Ofcourse I am not using EJB3.

The transaction_manager_lookup strategy in TopLink is driven by the property. This will allow TopLink to retrieve the transaction in JTA mode.

The only problem I have when using JTA + TopLink is the fact that MANUAL flushmode is not supported by the default PersistenceProvider (throws an UnsupportedOperationException DURING RENDERING while injecting the EntityManager in my POJO). The JoinTransaction (and enlist) works fine (when using the appropriate, but the UnsupportedOperationException kinda gets in the way of things 🙂

When using resource-local transactions (EntityTransaction), Seam again tries to set the MANUAL flushmode, but this time the exception is ignored /swallowed ( as it is called from the PersistenceContexts.changeFlushModes, BEFORE RENDERING) and processing continues. JoinTransaction is a no-op.

My experience with Seam is limited (only 2 days of trial & error), so I haven’t figured out yet why the manual flush mode UnsupportedOperationException is swallowed when using EntityTransactions, but thrown when using UTTransactions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: