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

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 weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Could we do this as a portable seam module?

-- Pete Muir http://in.relation.to/Bloggers/Pete On 30 Apr 2011, at 08:52, Johan Eltes <johan.eltes(a)callistaenterprise.se&gt; wrote: > 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 >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

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 >> >> >