Seam Managed Transactions and JMX MBeans

[felipevaa]

Hello!

First of all, I've been using JBoss Seam for the past 6 months, and I must say that it is just awesome!

I have recently migrated my app to Seam Managed Transactions (@In Entity Manager, instead of @PersistenceContext EntityManager) due to several LazyInitiationExceptions ocurring on a @CollectionOfElements property. Now everything is working great on the web front.

Then, I have introduced a JMX MBean, which calls an EJB which is using the Seam Managed EntityManager as I mentioned before. The EJB throws a NPE, because the EntityManager was not injected at the moment that the JMX Mbean called the EJB. Of course I could write another EJB using @PersistenceContext, but then I'm duplicating code, which wouldn't be the ideal solution.

My question is: What is the recommended way to deal with such scenario where EJBs under Seam Managed Transactions need to be share among Seam Web components and "outsider" JMX MBeans?

Thank you!

Felipe

[gavin.king]

The problem here is that there is no conversation context available in a call to an EJB that does not originate in the web tier. All I have is event and application contexts. I guess I should set up a little "temporary" conversation context, and a biz process context. I'll do that.

For now, your only option is to use @PersistenceContext.

[felipevaa]

Right on! I was debugging Seam today and came up to the same conclusion... The component managing the EntityManager has the conversation scope.

How can I contribute to this effort? I'm not very familiar with the Seam internals, but if you give me some pointers of what you have in mind, I could then perhaps implement some of this functionality.

Gavin, on a related topic... From a design perspective, how do you see the relationship between Seam and EJB on the long term? EJB3 was a *huge* improvement, but I really see Seam's component model taking over on the EJB front. This issue I faced is a good example: If I can call a Seam component from a JMX Service, and if Seam manages the transaction for me, why should I even care about EJBs at all??

I mean, I'm not saying that EJBs will disappear in favor of Seam. But perhaps EJB could be a "behind the scenes" type of architecture, whereas Seam is the framework where the developers really work on.

Felipe
PS: Thank you for your responsiveness.

[gavin.king]

How can I contribute to this effort?

No need, it is already fixed in CVS

From a design perspective, how do you see the relationship between Seam and EJB on the long term? EJB3 was a *huge* improvement, but I really see Seam's component model taking over on the EJB front.

EJB provides the solid foundation of a single component model that is re-usable in all kinds of environments. Seam provides the integration of this component model into the different environments (web-based applications, AJAX applications, ESB applications, rich-client applications, etc).

Things which are truly re-usable between these various environments should work their way back into the EJB spec.

This issue I faced is a good example: If I can call a Seam component from a JMX Service, and if Seam manages the transaction for me, why should I even care about EJBs at all??

Why is Seam managing the txn? It should not be, it is only managing the persistence context. I don't see any reason for introducing full-featured declarative tx, security and state management at the level of Seam. (Though we may decide to provide integration of something like Acegi, if someone can ever properly explain to me its value.)

Yes, I _could_ build this stuff into Seam, but then I would be essentially reimplementing EJB3, in a nonstandard way, so what would be the point?