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

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