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

[Werner Keil]

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