On Nov 17, 2015, at 9:25 AM, Werner Keil <werner.keil(a)gmail.com&gt; wrote: Looking at the EG of JSR 236 however, other than 2 JCP Award winners in the member category (Doug Lea and Adam Bien, the latter did however admit when he picked his award, he wasn't sure who nominated him, and that at least when it comes to active involvement in JSRs he was far from active in any of them;-) there are pretty much the "Big 3" IBM, Oracle Red Hat (in alphabetical order) only in that EG. So should Oracle prefer someone took the Spec Lead role for Java EE Concurrency.next, who other than those Big 3 would be a suitable Spec Lead or Co Spec Lead? I know what it means, since I am also Spec Lead of an active JSR, but that is more than enough until that's gone final. Sure, there are other Individual or corporate members in this and other EE EGs who might be a good fit for that aside from say the obvious Doug Lea;-) Werner > On Tue, Nov 17, 2015 at 1:51 PM, <cdi-dev-request(a)lists.jboss.org&gt; wrote: > Send cdi-dev mailing list submissions to > cdi-dev(a)lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request(a)lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner(a)lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Nov 2015 15:17:58 +0100 > From: Werner Keil <werner.keil(a)gmail.com&gt; > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Message-ID: > <CAAGawe1FFg7bJazj67gpXXEKBJ8Qu+v9yAxECaEdmgoTr2-hHQ(a)mail.gmail.com&gt; > Content-Type: text/plain; charset="utf-8" > > Reza/all, > > Do you suggest, others could/should take over as Spec Lead of a new Java EE > Concurrency JSR or just gather ideas and do brainstorming, similar to e.g. > what happens in JSR 375? > > Werner > > > > On Tue, Nov 17, 2015 at 1:37 PM, <cdi-dev-request(a)lists.jboss.org&gt; wrote: > > > Send cdi-dev mailing list submissions to > > cdi-dev(a)lists.jboss.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > or, via email, send a message with subject or body 'help' to > > cdi-dev-request(a)lists.jboss.org > > > > You can reach the person managing the list at > > cdi-dev-owner(a)lists.jboss.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of cdi-dev digest..." > > > > > > Today's Topics: > > > > 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) > > 2. Re: [PROPOSAL] further align CDI and EJB (Antonio Goncalves) > > 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 16 Nov 2015 18:55:04 -0500 > > From: Reza Rahman <reza.rahman(a)oracle.com&gt; > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > > Message-ID: <ECA2AF54-612C-4495-A8D2-04092A0110BB(a)oracle.com&gt; > > Content-Type: text/plain; charset=utf-8 > > > > 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. > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 17 Nov 2015 14:44:35 +0100 > > From: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: Reza Rahman <reza.rahman(a)oracle.com&gt; > > Cc: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > > Message-ID: > > < > > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ(a)mail.gmail.com&gt; > > Content-Type: text/plain; charset="utf-8" > > > > 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(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 > > > > > > 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> > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/at... > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 17 Nov 2015 15:03:32 +0100 > > From: arjan tijms <arjan.tijms(a)gmail.com&gt; > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; > > Cc: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > > Message-ID: > > <CAE=- > > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ(a)mail.gmail.com&gt; > > Content-Type: text/plain; charset="utf-8" > > > > 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 <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. > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/at... > > > > ------------------------------ > > > > _______________________________________________ > > 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. > > > > End of cdi-dev Digest, Vol 60, Issue 13 > > *************************************** > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/b1fb79c2/at... > > ------------------------------ > > _______________________________________________ > 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. > > End of cdi-dev Digest, Vol 60, Issue 14 > *************************************** _______________________________________________ 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.