I would actually think Weld could/should expose this, not CDI. As exposing TM is definitely not per spec, hence not CDI's "business". Otoh, building Tx based Seam3 components would again depend on Weld workaround; e.g. Seam Conversation.
TM also exposes XAResource handling, for which TxServices don't have matching api. And like I said, there is also suspend/resume Tx API, which sometimes also comes in handy. If TxServices::getTM returns an actual TM instance, then Weld could expose it as a bean. But purely optional from the Services implementor --> null TM == no TM bean. -Ales On Apr 30, 2011, at 1:10 PM, Pete Muir wrote: > I'm not 100% sure what you mean, as TransactionServices exposes services to > Weld which uses them to (a) expose UTX as a bean and (b) register for > synchronizations for TX events. So just adding TM to TransactionServices > won't do very much ;-), you would also need to expose TM as a bean. Weld > could do this, but in general in Weld we've tried to avoid exposing built in > beans (especially for standard APIs) which aren't spec defined as this could > interfere with other people. So better to propose this for CDI 1.1 IMO. > > On 29 Apr 2011, at 17:26, Ales Justin wrote: > >> IMO TransactionServices should also expose TransactionManager. >> >> Since with AS7, which hides TM from JNDI, one cannot easily register >> XAResources: >> >> Transaction >> public boolean enlistResource(XAResource xaRes) throws RollbackException, >> IllegalStateException, SystemException >> >> or suspending/resuming current Tx. >> Specially XAResources handling is a must to be able to enlist if you're >> doing some non-trivial tx-based work. >> >> This way the integration layer would make sure the TM is exposed as a CDI >> service. >> >> Wdyt? >> >> -Ales >> >> > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
