-
1. Re: Seam Managed Transactions and JMX MBeans
gavin.king Jun 16, 2006 10:38 PM (in response to felipevaa)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. -
2. Re: Seam Managed Transactions and JMX MBeans
felipevaa Jun 17, 2006 4:57 AM (in response to 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. -
3. Re: Seam Managed Transactions and JMX MBeans
gavin.king Jun 17, 2006 3:54 PM (in response to felipevaa)How can I contribute to this effort?
No need, it is already fixed in CVSFrom 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?