jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: JSR 236

From: Pete Muir <pmuir_at_bleepbleep.org.uk>
Date: Tue, 12 Feb 2013 14:37:32 +0000

On 11 Feb 2013, at 20:29, Bill Shannon wrote:

> Pete Muir wrote on 02/11/13 02:25:
>> Hi Linda
>>
>> Apologies for the late reply.
>>
>> (1) It should be included in the full platform
>> (2) Probably not.
>>
>> I've also had quite a few comments that the spec is missing CDI
>> integration. I've cc'd David, our spec rep, so he can communicate
>> this to the JSR-236 EG as well.
>
> (I didn't see a Cc on your original message.)

I suspect a list swallowed it.

>
>> * Support injecting into tasks (runnable and callable) using all
>> types of injection - constructor, method and field
>
> The JSR 236 implementation is not creating the task instances.
> If you inject the task instance into your class, and then pass
> that task instance to the JSR 236 API, that task instance can
> make use of injection. Similarly, you could create that task
> instance dynamically using the various CDI APIs and the task
> instance can make use of injection.

Gotcha, makes sense.

>
>> * support injecting a default managed executor services using @Inject
>> natively
>
> This is just another example of the "default producers" issue we've
> discussed, and which we decided not to address for this release, but
> would like to address in the future.

I would disagree. In some cases a default producer makes sense, in others it 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.

>
>> * Show examples of using resource producers to map alternative
>> managed executor services to CDI injection (as we normally do for
>> @Resource)
>
> I don't think we need every spec that defines a resource to reiterate
> this CDI technique.
>
>> * Support propagation or creation of new CDI contexts for tasks,
>> mapping section 2.3 to CDI contexts as appropriate (looks to me like
>> just the application context)
>
> Yes, defining the CDI context for tasks is an open issue. And yes,
> for now, it looks like they have only application context.

Great.

>
>> * Support for @Transactional as well as EJB transactions
>
> I don't understand the issue here. I would expect that tasks support
> these in the same way that other classes support them.

Right, however the spec could show this.

>
>> * support injecting a default managed scheduled executor services
>> using @Inject natively
>> * Show examples of using resource producers to map alternative
>> managed scheduled executor services to CDI injection (as we normally
>> do for @Resource)
>> * Show examples of using resource producers to map context services
>> to CDI injection (as we normally do for @Resource)
>> * support injecting a default managed thread factory using @Inject
>> natively
>> * Show examples of using resource producers to map alternative
>> managed thread factories to CDI injection (as we normally do for
>> @Resource)
>
> As above.
>
>> With these changes, I think this will be a really excellent set of
>> services for Java EE, and fill a big gap in the programming model
>> for users.
>>
>> It would also be interesting to explore the relationship between CDI events and JSR-236 in the future.
>>
>> I really like the spec overall, particularly as it's really focused
>> on not reinventing the wheel, but on trying to stick to existing
>> designs as close as possible.
>
> Thanks for the feedback!