Bill/all,
On Mon, Feb 11, 2013 at 9:29 PM, Bill Shannon <bill.shannon_at_oracle.com>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.)
>
> > * 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.
>
> > * 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.
>
> > * 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.
>
>
+1
At the moment, 236 has some strange interface called "ContextService", but
it has nothing to do with CDI or Context in the sense of it.
Its purpose is documented as * The ContextService provides methods for
creating dynamic proxy objects
So as a gut feeling, I probably would have called it ConcurrencyService
rather than ContextService, given the only context it means to interact is
the good old
InitialContext ctx = new InitialContext();
of JNDI.
Most of it feels a bit "dusty", glad, a few of these surfaces may get a bit
cleaner and better integrated with today's EE, and maybe others have to be
addressed in the next version?
> > * 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.
>
> > * 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!
>
Werner