Just curious: what would be the benefit of this in comparison to the standard route, which would be to implement a custom JCA connector?
/Johan On 30 apr 2011 v17, at 14.18, Ales Justin wrote: > 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 _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
