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.

From my POV problems are: - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) - EJB spec won't be reopened except for minor MR - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. Antoine Le jeu. 12 nov. 2015 à 11:17, Tomas Remes <tremes(a)redhat.com&gt; a écrit : > > I think nothing will happen in EJB spec so I would not really rely on > some future collaboration. Another case is this classpath scanning and > AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at > least at first glance.:) But the question is: Isn't it late to propose any > new JSR for upcoming EE 8? I guess it is so this seems to me bit out of > scope for CDI 2.x... maybe CDI 3?:) > > Tom > > ----- Original Message ----- > From: "Sven Linstaedt" <sven.linstaedt(a)gmail.com&gt; > To: "Romain Manni-Bucau" <rmannibucau(a)gmail.com&gt; > Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org&gt; > Sent: Thursday, November 12, 2015 10:45:22 AM > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > +1 for splitting the classpath scanning and all AnnotatedXXX / > ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, > so other specs (not only EJB) may rely on it. > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau(a)gmail.com > : > > > > Hi Mark, > > few points on that topic: > > - let the EJB container reuse AnnotatedType (ie even add @Stateless > through an Extension): +1 > - veto an EJB as a whole and not only in CDI side - ie @Schedule is > ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it > would break the compatibility with extsing apps I fear since veto is 100% a > CDI thing today. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg(a)yahoo.de > : > > > 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. > > -- > Tomas Remes > > > > _______________________________________________ > 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.

So why wouldn’t the entire EE ecosystem be described at the EE level?

Am 12.11.2015 um 13:51 schrieb John D. Ament <john.d.ament(a)gmail.com&gt;: Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: From my POV problems are: - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) - EJB spec won't be reopened except for minor MR - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. Antoine Le jeu. 12 nov. 2015 à 11:17, Tomas Remes <tremes(a)redhat.com&gt; a écrit : I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) Tom ----- Original Message ----- From: "Sven Linstaedt" <sven.linstaedt(a)gmail.com&gt; To: "Romain Manni-Bucau" <rmannibucau(a)gmail.com&gt; Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org&gt; Sent: Thursday, November 12, 2015 10:45:22 AM Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau(a)gmail.com > : Hi Mark, few points on that topic: - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg(a)yahoo.de > : 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. -- Tomas Remes _______________________________________________ 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.

Am 13.11.2015 um 09:49 schrieb Sven Linstaedt <sven.linstaedt(a)gmail.com&gt;: Well, that was my point of splitting out these metadata scanning and processing into an independent spec, which CDI will depend on and maybe EJB in some future too, if their EG adopts it. As there is no global inter-spec coordination for - Mark called it - "EE umbrella" one can simply have a chat with them and keep the fingers crossed. br, Sven 2015-11-12 17:00 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: > So why wouldn’t the entire EE ecosystem be described at the EE level? Perfectly nailed. But here is the problem: the EE umbrella does NOT do code. It does NOT provide an own TCK. It just packages together the other specs (and sometimes imposes restrictions and additional features on it). LieGrue, strub > Am 12.11.2015 um 13:51 schrieb John D. Ament <john.d.ament(a)gmail.com&gt;: > > Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. > > The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. > > The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? > > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: > From my POV problems are: > > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) > - EJB spec won't be reopened except for minor MR > - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. > > Antoine > > Le jeu. 12 nov. 2015 à 11:17, Tomas Remes <tremes(a)redhat.com&gt; a écrit : > > I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) > > Tom > > ----- Original Message ----- > From: "Sven Linstaedt" <sven.linstaedt(a)gmail.com&gt; > To: "Romain Manni-Bucau" <rmannibucau(a)gmail.com&gt; > Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org&gt; > Sent: Thursday, November 12, 2015 10:45:22 AM > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau(a)gmail.com > : > > > > Hi Mark, > > few points on that topic: > > - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 > - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg(a)yahoo.de > : > > > 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. > > -- > Tomas Remes > > > > _______________________________________________ > 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.

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).

* 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).

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.

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.

> >> * 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.

> >> >> 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.

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.

On Nov 17, 2015, at 9:03 AM, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: Hi, > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: > @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. 100% agree with this. It's almost better not to do things if absolutely needed, then burden CDI with some concerns it perhaps should not be concerned with. It's already problematic that CDI crossed this bridge once with providing a Bean<T> for Servlet and other artifacts it doesn't own. As for @Asynchronous, a basic prototype implementation has already been created by several parties. I did one here: http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld team did one here: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o... Also interesting would be to go a little beyond what the EJB vesion offers and add support for a completable feature and optionally named thread pools. Kind regards, Arjan Tijms > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > 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.