On 02/05/2011, at 1:19 AM, Pete Muir wrote:

> Could we do this as a portable seam module?
> 

This should be quite easy, Seam Persistence already has code that checks 
various JNDI locations for the TM. 

Stuart

> --
> Pete Muir
> http://in.relation.to/Bloggers/Pete
> 
> On 30 Apr 2011, at 08:52, Johan Eltes <[email protected]> 
> 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
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
> 
> _______________________________________________
> 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

Reply via email to