[cdi-dev] [PROPOSAL] further align CDI and EJB
Werner Keil
werner.keil at gmail.com
Tue Nov 17 09:25:22 EST 2015
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 at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at 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 at gmail.com>
> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <
> CAAGawe1FFg7bJazj67gpXXEKBJ8Qu+v9yAxECaEdmgoTr2-hHQ at mail.gmail.com>
> 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 at lists.jboss.org> wrote:
>
> > Send cdi-dev mailing list submissions to
> > cdi-dev at 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 at lists.jboss.org
> >
> > You can reach the person managing the list at
> > cdi-dev-owner at 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 at oracle.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> > Message-ID: <ECA2AF54-612C-4495-A8D2-04092A0110BB at oracle.com>
> > 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 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.
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 17 Nov 2015 14:44:35 +0100
> > From: Antonio Goncalves <antonio.goncalves at gmail.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: Reza Rahman <reza.rahman at oracle.com>
> > Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> > Message-ID:
> > <
> > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ at mail.gmail.com>
> > 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 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-0001.html
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 17 Nov 2015 15:03:32 +0100
> > From: arjan tijms <arjan.tijms at gmail.com>
> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB
> > To: Antonio Goncalves <antonio.goncalves at gmail.com>
> > Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> > Message-ID:
> > <CAE=-
> > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves <
> > antonio.goncalves at gmail.com> 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/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >
> > 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 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>
> > >
> > > _______________________________________________
> > > 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.
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment.html
> >
> > ------------------------------
> >
> > _______________________________________________
> > 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.
> >
> > 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/attachment.html
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 60, Issue 14
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/5c37daa9/attachment-0001.html
More information about the cdi-dev
mailing list