[javaee-spec users] [jsr342-experts] Re: JSR 236
- From: Bill Shannon <bill.shannon@...>
- To: Anthony Lai <ANTHONY.LAI@...>
- Cc: jsr342-experts@...
- Subject: [javaee-spec users] [jsr342-experts] Re: JSR 236
- Date: Thu, 14 Feb 2013 14:01:55 -0800
- List-id: <jsr342-experts.javaee-spec.java.net>
Anthony, please make sure the JSR 236 spec is clear that tasks/threads
have the same ability to use transactions that the component submitting
them does. For example, they can call transactional enterprise beans,
they can call managed beans that use the @Transactional interceptor,
they can start their own transactions using UserTransaction, etc.
Pete Muir wrote on 02/14/2013 06:35 AM:
> On 14 Feb 2013, at 00:58, Bill Shannon wrote:
>> Pete Muir wrote on 02/12/13 06:37:
>>>>> * support injecting a default managed executor services using @Inject
>>>> This is just another example of the "default producers" issue we've
>>>> discussed, and which we decided not to address for this release, but
>>>> like to address in the future.
>>> I would disagree. In some cases a default producer makes sense, in others
>>> doesn't. Here it does, so we should support it. Just because something
>>> doesn't always make sense isn't a reason to never do it.
>> I agree. And I agree that we should support it, once we have a general
>> strategy for supporting default producers. There are other cases that
>> make sense as well, but that we deferred because we hadn't worked through
>> all the technical issues. I'd like to see us do that for EE 8.
>>>>> * Support for @Transactional as well as EJB transactions
>>>> I don't understand the issue here. I would expect that tasks support
>>>> in the same way that other classes support them.
>>> Right, however the spec could show this.
>> I don't think the JSR 236 spec needs examples showing tasks doing all the
>> things that a Java EE application class can do.
>> Is there some reason you think it especially needs an example of
>> If you think there's any question about whether tasks can use transactions
>> at all, we could clarify that.
> Right, this is the reason I am suggesting it.