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

@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(a)oracle.com&gt; 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(a)gmail.com&gt; > wrote: > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com&gt;: > >> Responses in-line: > >> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > rmannibucau(a)gmail.com&gt; wrote: > >>> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman <reza.rahman(a)oracle.com&gt;: > >>>> 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(a)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(a)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(a)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> _______________________________________________ cdi-dev mailing list cdi-dev(a)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.