[cdi-dev] [PROPOSAL] further align CDI and EJB

Tue Nov 17 08:44:35 EST 2015

HI all,

This discussion comes back on and off.

At the last F2F meeting, we talked about having @Startup and @Shutdown in
JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the
spec. No need to have @DependsOn as we will use @Priority with @Startup.

@Schedule should go to Java EE Concurrency (implemented as a CDI
interceptor) but not in CDI as this would be just moving more stuff inside
CDI (which will end up as big as EJBs). Same for @Asynchronous.

So what could be doable in CDI 2.1 is having @Startup and @Shutdown
implemented... but the annotations would be in JSR 250.

Antonio

On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman <reza.rahman at oracle.com>
wrote:

> One good thing is that Oracle has not yet filed a JSR for Java EE
> concurrency utilities targeting Java EE 8. That means any interested
> parties could do so and perhaps that could be better for the community in
> the end anyway.
>
> Certainly starting prototyping some of these things will make it clearer
> where they belong or could be contributed to in the end.
>
> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
> >
> > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman at oracle.com>:
> >> Responses in-line:
> >>
> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
> >>>
> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman at oracle.com>:
> >>>> In terms of CDI and EJB alignment, I think these would have the most
> >>>> value to the community going forward:
> >>>>
> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has
> >>>> similarly nice syntax to handle eager loading).
> >>>
> >>> @Startup is there with @Initialized(ApplicationScoped) event
> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy
> >>> and full of proxies so not sure it would bring much to the game
> >>> without bringing really much more like @Schedule etc...
> >>
> >> Yes, I know but eager loading is a common enough case to warrant better
> syntax/usability.
> >
> > fair enough
> >
> >>>
> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for
> CDI.
> >>>> These are very useful bits of functionality that should be available
> to
> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be
> >>>> extremely useful. EJB @Schedule is similarly useful but likely not
> right
> >>>> for CDI proper as it does not have that much to do with component
> >>>> life-cycle/bean access management. The others I think are quite
> natural
> >>>> fits for the core of a DI framework (in fact it may be awkward to have
> >>>> them elsewhere).
> >>>
> >>>
> >>> Think concurrency utilities can have a CDI integration rather than
> >>> putting everything in CDI. It is globally all interceptors - at least
> >>> in term of design - so would make sense to have them outside IMO - but
> >>> a big +1 to get them cleanly added on top of CDI.
> >>
> >> Keep in mind, Java EE concurrency utilities is also minimally resourced
> and that's unlikely to change in the future. I would say if we think these
> features would help community/CDI adoption, it's likely wisest to find a
> way to do it in CDI proper. As I alluded to, these are also a bit easier to
> implement at the core DI container level than via interceptors. Things like
> @Transcational, @Schedule are easier as interceptors since they don't have
> as much to do with the internals of the component life-cycle and instance
> access control.
> >
> > well yes and not, it would be awesome to control where the concurrency
> > is exactly in the stack and it would mean being able to change
> > @Priority for instance.
> >
> > Overall point being that if we put features only where resources are
> > instead of trying to put them where they fit and try to help these
> > specs CDI will likely handle javascript integration soon ;).
> >
> > Concurrency and throttling have a potential spec which would be
> > welcomed in these very distributed days, we just need to find people
> > motivated enough to make it moving forward IMO.
> >
> >>>
> >>>>
> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB
> be
> >>>> at this stage. If there is a compelling reason that helps the platform
> >>>> and CDI generally we can see if it can be done. By default, EJB is
> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to
> >>>> change at this stage. In the community I have mostly seen requests for
> >>>> moving functionality out of EJB into CDI rather than the other way
> around...
> >>>>
> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote:
> >>>>> Hi!
> >>>>>
> >>>>> We already do a decent amount of ‚side-by-side‘ handling in EJB and
> CDI. But there are still many aready where we could really move together
> much closer.
> >>>>>
> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by
> the EJB container. But what happens with ProcessAnnotatedType#veto(). This
> one is not defined that clearly I fear.
> >>>>>
> >>>>> What if we (of course together with the EJB spec group) define that
> the EJB container must create the EJBs according to the effective
> AnnotatedType coming out after ProcessAnnotatedType? This would define that
> EJBs can also get modified via CDI Extensions. Some container do that
> already.
> >>>>> The benefit of explicitly writing this down would obviously be that
> we would allow EJB to fully utilize the power of CDI Extensions in a
> portable way.
> >>>>>
> >>>>> Any objections, any ideas, any howtos?
> >>>>>
> >>>>> Let the ideas roll ;)
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>> _______________________________________________
> >>>>> cdi-dev mailing list
> >>>>> cdi-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>>
> >>>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>>
> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> cdi-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>

-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment.html 