Hi guys, CDI lite is one of the big feature we are expected to deliver for version 2.0. I think it's time to start discussing about its design. The big picture is to provide a consistent subset of CDI that could be implemented like Dagger is (code generated with process annotation). This would allow using CDI in constrained environment like mobile or embedded devices. IMO CDI lite should be targeted to Java SE (I don't think it would make sense for Java EE). So, from a specification perspective, we''l probably have to split core part in 2 and se part as well (gosh). I'm not sure regarding API. today they only weight 72 KB, so creating a subset only for the sake of the weight doesn't make sense. the only reason would be to have something clearer for the end user. but that could be tricky. Antoine _______________________________________________ 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.

Hi all, With my strong Java EE background, sentences like "IMO CDI lite should be targeted to Java SE", hurt ;o) I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6), and their answer for not adopting CDI was "too heavy". Today, a JBoss project called JBoss Forge (Java SE) is "dumping" CDI from its internals because it's too slow (George, could you develop a bit more this topic?). What do these two projects have in common ? They just need a "light" dependency injection framework. I was talking to the Forge guys (I think it was Lincoln) and, basically, they just need @Inject, @Qualifier and @Produces (the missing one). My question is : do we need a CDI Lite, or do we need a "fatter" @Inject (for both SE and EE) ? I think that if we manage to move producers (and disposers) to JSR 330, then CDI would do the rest, no need for a Ligther version. WDYT ? Antonio PS : With Antoine we talked to Juergen (co-spec lead od 330) and Patrick Curran (JCP Chair man) and it looks like another lead could take over 330 (I'm imagining RedHat talking the Lead role on 330). Even a maintenance release would be doable On Fri, Aug 28, 2015 at 11:35 AM, Antoine Sabot-Durand < antoine(a)sabot-durand.net&gt; wrote: > Hi guys, > > CDI lite is one of the big feature we are expected to deliver for version > 2.0. I think it's time to start discussing about its design. > > The big picture is to provide a consistent subset of CDI that could be > implemented like Dagger is (code generated with process annotation). This > would allow using CDI in constrained environment like mobile or embedded > devices. > > IMO CDI lite should be targeted to Java SE (I don't think it would make > sense for Java EE). So, from a specification perspective, we''l probably > have to split core part in 2 and se part as well (gosh). > > I'm not sure regarding API. today they only weight 72 KB, so creating a > subset only for the sake of the weight doesn't make sense. the only reason > would be to have something clearer for the end user. but that could be > tricky. > > Antoine > > _______________________________________________ > 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>

On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6), > and their answer for not adopting CDI was "too heavy". I can't find an exact reference anymore, but I somewhat remember that one of the reasons was also simply that CDI as a general solution finished late in Java EE 6, while JAX-RS finished earlier and had all the work for their own DI solution already done.

On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6), > and their answer for not adopting CDI was "too heavy". I can't find an exact reference anymore, but I somewhat remember that one of the reasons was also simply that CDI as a general solution finished late in Java EE 6, while JAX-RS finished earlier and had all the work for their own DI solution already done.

@Antoine, so which content do you see in CDI Lite ? Are you sure about events ? I'm in favor of a "fatter" 330 that would have : - @Inject : already there - @Qualifier : already there - *Producers and disposers * - *Programatic lookup * - *Java SE Bootstrap* When you say "*The goal here is not to propose a new EE profile but a subspec*", 330 could already be seen as a subspec. If you put events apparts, what would be missing in this list in your point of view ? And what obstacles do you see in archieving this ? To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all thing) ? Antonio On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand < antoine(a)sabot-durand.net&gt; wrote: > Yes Arjan, I think it's the first reason. We really should work with them > to understand what should be added to CDI 2.0 to have it as a first citizen > DI in their spec. > > Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com&gt; a > écrit : > >> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >> <antonio.goncalves(a)gmail.com&gt; wrote: >> > I remember talking with the JAX-RS guys (Java EE), years ago (back in >> EE6), >> > and their answer for not adopting CDI was "too heavy". >> >> I can't find an exact reference anymore, but I somewhat remember that >> one of the reasons was also simply that CDI as a general solution >> finished late in Java EE 6, while JAX-RS finished earlier and had all >> the work for their own DI solution already done. >> > -- 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.

Personally, I'm not in favor of a slimmed down runtime. It was tried with EJB, but never implemented properly (most implementations that support EJB-lite actually support the entire thing, except for deprecated stuff).

I think if we define SE properly we won't have a need for this. John On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves < antonio.goncalves(a)gmail.com&gt; wrote: > @Antoine, so which content do you see in CDI Lite ? Are you sure about > events ? > > I'm in favor of a "fatter" 330 that would have : > > - @Inject : already there > - @Qualifier : already there > - > *Producers and disposers * > - > *Programatic lookup * > - *Java SE Bootstrap* > > When you say "*The goal here is not to propose a new EE profile but a > subspec*", 330 could already be seen as a subspec. If you put events > apparts, what would be missing in this list in your point of view ? And > what obstacles do you see in archieving this ? > > To boostrap CDI we have a CDIProvider, why not having an > InjectionProvider just to bootstrap 330 (then, CDIProvider could extend > InjectionProvider, so it bootstraps the all thing) ? > > Antonio > > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand < > antoine(a)sabot-durand.net&gt; wrote: > >> Yes Arjan, I think it's the first reason. We really should work with >> them to understand what should be added to CDI 2.0 to have it as a first >> citizen DI in their spec. >> >> Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com&gt; a >> écrit : >> >>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >>> <antonio.goncalves(a)gmail.com&gt; wrote: >>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in >>> EE6), >>> > and their answer for not adopting CDI was "too heavy". >>> >>> I can't find an exact reference anymore, but I somewhat remember that >>> one of the reasons was also simply that CDI as a general solution >>> finished late in Java EE 6, while JAX-RS finished earlier and had all >>> the work for their own DI solution already done. >>> >> > > > -- > 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. _______________________________________________ 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.

It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he forked 330 because he found CDI was doing too much ;o) For me, "CDI Lite" was just basic dependency injection. The fact that CDI can now run on SE (like JPA....), is good... but for me it has nothing to do with Light : it's the entire thing that can bootstrap in SE. Good. So what is Lite for you guys ? Antonio On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com > wrote: > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com&gt;: > >> Personally, I'm not in favor of a slimmed down runtime. It was tried >> with EJB, but never implemented properly (most implementations that support >> EJB-lite actually support the entire thing, except for deprecated stuff). >> >> > +1, most of CDI is basic and quickly any light version will miss events > or other thing - in particular in maintaining micro services from > experience. Size of an implementation can easily be < 1M so not sure it > would bring anything. Only important point is what Antoine started to do ie > ensuring EE and SE parts are clearly identified and split in the spec. > > >> I think if we define SE properly we won't have a need for this. >> >> John >> >> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves < >> antonio.goncalves(a)gmail.com&gt; wrote: >> >>> @Antoine, so which content do you see in CDI Lite ? Are you sure about >>> events ? >>> >>> I'm in favor of a "fatter" 330 that would have : >>> >>> - @Inject : already there >>> - @Qualifier : already there >>> - >>> *Producers and disposers * >>> - >>> *Programatic lookup * >>> - *Java SE Bootstrap* >>> >>> When you say "*The goal here is not to propose a new EE profile but a >>> subspec*", 330 could already be seen as a subspec. If you put events >>> apparts, what would be missing in this list in your point of view ? And >>> what obstacles do you see in archieving this ? >>> >>> To boostrap CDI we have a CDIProvider, why not having an >>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend >>> InjectionProvider, so it bootstraps the all thing) ? >>> >>> Antonio >>> >>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand < >>> antoine(a)sabot-durand.net&gt; wrote: >>> >>>> Yes Arjan, I think it's the first reason. We really should work with >>>> them to understand what should be added to CDI 2.0 to have it as a first >>>> citizen DI in their spec. >>>> >>>> Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com&gt; a >>>> écrit : >>>> >>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >>>>> <antonio.goncalves(a)gmail.com&gt; wrote: >>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back >>>>> in EE6), >>>>> > and their answer for not adopting CDI was "too heavy". >>>>> >>>>> I can't find an exact reference anymore, but I somewhat remember that >>>>> one of the reasons was also simply that CDI as a general solution >>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all >>>>> the work for their own DI solution already done. >>>>> >>>> >>> >>> >>> -- >>> 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. >> >> >> _______________________________________________ >> 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>

For me, a Light version of CDI is clearly the features number. That's why I don't see events in it. For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring has @Bean, then it's because 330 lakes this functionality.

On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com > wrote: > Lite can have several definition, let's try to list them up if it can > help: > > - binary size: for me until 3M for an app it is "Lite" > - features number: the whole IoC set of feature is light since you almost > always need it, it means you can do lighter but it wouldnt be used - check > spring, who uses only spring-ioc and not context or more? > - features complexity: sure we are not light here but supporting scopes > already breaks "Lite-ness" IMO so not a real issue > > So my view is CDI "SE" is light enough - as a spec and spec can't affect > implementations so seems the fight is not on the right side to me. > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)gmail.com > >: > >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he >> forked 330 because he found CDI was doing too much ;o) >> >> For me, "CDI Lite" was just basic dependency injection. The fact that >> CDI can now run on SE (like JPA....), is good... but for me it has nothing >> to do with Light : it's the entire thing that can bootstrap in SE. Good. >> >> So what is Lite for you guys ? >> >> Antonio >> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau < >> rmannibucau(a)gmail.com&gt; wrote: >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com&gt;: >>> >>>> Personally, I'm not in favor of a slimmed down runtime. It was tried >>>> with EJB, but never implemented properly (most implementations that support >>>> EJB-lite actually support the entire thing, except for deprecated stuff). >>>> >>>> >>> +1, most of CDI is basic and quickly any light version will miss events >>> or other thing - in particular in maintaining micro services from >>> experience. Size of an implementation can easily be < 1M so not sure it >>> would bring anything. Only important point is what Antoine started to do ie >>> ensuring EE and SE parts are clearly identified and split in the spec. >>> >>> >>>> I think if we define SE properly we won't have a need for this. >>>> >>>> John >>>> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves < >>>> antonio.goncalves(a)gmail.com&gt; wrote: >>>> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure >>>>> about events ? >>>>> >>>>> I'm in favor of a "fatter" 330 that would have : >>>>> >>>>> - @Inject : already there >>>>> - @Qualifier : already there >>>>> - >>>>> *Producers and disposers * >>>>> - >>>>> *Programatic lookup * >>>>> - *Java SE Bootstrap* >>>>> >>>>> When you say "*The goal here is not to propose a new EE profile but >>>>> a subspec*", 330 could already be seen as a subspec. If you put >>>>> events apparts, what would be missing in this list in your point of view ? >>>>> And what obstacles do you see in archieving this ? >>>>> >>>>> To boostrap CDI we have a CDIProvider, why not having an >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend >>>>> InjectionProvider, so it bootstraps the all thing) ? >>>>> >>>>> Antonio >>>>> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand < >>>>> antoine(a)sabot-durand.net&gt; wrote: >>>>> >>>>>> Yes Arjan, I think it's the first reason. We really should work with >>>>>> them to understand what should be added to CDI 2.0 to have it as a first >>>>>> citizen DI in their spec. >>>>>> >>>>>> Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com&gt; a >>>>>> écrit : >>>>>> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >>>>>>> <antonio.goncalves(a)gmail.com&gt; wrote: >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago >>>>>>> (back in EE6), >>>>>>> > and their answer for not adopting CDI was "too heavy". >>>>>>> >>>>>>> I can't find an exact reference anymore, but I somewhat remember >>>>>>> that >>>>>>> one of the reasons was also simply that CDI as a general solution >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had >>>>>>> all >>>>>>> the work for their own DI solution already done. >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> _______________________________________________ >>>> 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> >> > > -- 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>

For me, a Light version of CDI is clearly the features number. That's why I don't see events in it.

For me, a Light version of CDI is clearly the features number. That's why I don't see events in it.

I don't see Events in a "Lite" version because the other DI frameworks don't use them. A "fatter" 330 with producers, programmatic lookup and bootstrap, could be "easily" implemented by Spring, Guice... If we leave events in a Lite version, then it won't be the case, and Weld and OWB will be the only two implementations. For me, a Lite version would just be about DI. If Weld uses events internally to archieve basic DI, well, it's just an implementation decision, not a spec. I would not even try to standardize the way @Inject works (like Romain said, @Inject doesn't work the same in Weld or Spring), let's leave it like this. If you take back Antoine sentence "*This would allow using CDI in constrained environment like mobile or embedded devices*", then I don't think events would fit here. Antonio On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > > For me, a Light version of CDI is clearly the features number. That's > why I don't see events in it. > > We did discuss this last year on the f2f meeting. The problem lies within > our Extension mechanism. Without events you also need to drop the Extension > mechanism. And to be honest, this is THE major hit in all CDI… > Sorry to be the bad guy busting all those ideas. I really don’t want to, > but better now than too late down the road ;) > > It’s really tricky as many features are heavily based on each other. E.g. > by removing scanning you could get rid of javassist/asm/etc ? nope, we also > have our class proxies which need bytecode tinkering. So remove > interceptors and decorators too? Well yea, but we still have normalscoping > -> what is left? basically spring prototype and singleton. Hmm. that’s not > that much compared to full CDI. And all that for only 200kByte? > (Btw we also discussed generating the bytecode classes at build time, but > then we still miss the dynamics we get from Extensions, e.g. PAT adding an > interceptor annotation) > Just to give you a rough idea how this all works together when it comes > to implementation details… > Please feel free to ask Jozef and me for further infos on ‚dependencies‘. > > LieGrue, > strub > > > > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves < > antonio.goncalves(a)gmail.com&gt;: > > > > For me, a Light version of CDI is clearly the features number. That's > why I don't see events in it. > > > > For me, a CDI Lite would just focus on DI. If CDI has @Produces and > Spring has @Bean, then it's because 330 lakes this functionality. > > > > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau < > rmannibucau(a)gmail.com&gt; wrote: > > Lite can have several definition, let's try to list them up if it can > help: > > > > - binary size: for me until 3M for an app it is "Lite" > > - features number: the whole IoC set of feature is light since you > almost always need it, it means you can do lighter but it wouldnt be used - > check spring, who uses only spring-ioc and not context or more? > > - features complexity: sure we are not light here but supporting scopes > already breaks "Lite-ness" IMO so not a real issue > > > > So my view is CDI "SE" is light enough - as a spec and spec can't > affect implementations so seems the fight is not on the right side to me. > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves < > antonio.goncalves(a)gmail.com&gt;: > > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he > forked 330 because he found CDI was doing too much ;o) > > > > For me, "CDI Lite" was just basic dependency injection. The fact that > CDI can now run on SE (like JPA....), is good... but for me it has nothing > to do with Light : it's the entire thing that can bootstrap in SE. Good. > > > > So what is Lite for you guys ? > > > > Antonio > > > > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau < > rmannibucau(a)gmail.com&gt; wrote: > > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com&gt;: > > Personally, I'm not in favor of a slimmed down runtime. It was tried > with EJB, but never implemented properly (most implementations that support > EJB-lite actually support the entire thing, except for deprecated stuff). > > > > > > +1, most of CDI is basic and quickly any light version will miss events > or other thing - in particular in maintaining micro services from > experience. Size of an implementation can easily be < 1M so not sure it > would bring anything. Only important point is what Antoine started to do ie > ensuring EE and SE parts are clearly identified and split in the spec. > > > > I think if we define SE properly we won't have a need for this. > > > > John > > > > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves < > antonio.goncalves(a)gmail.com&gt; wrote: > > @Antoine, so which content do you see in CDI Lite ? Are you sure about > events ? > > > > I'm in favor of a "fatter" 330 that would have : > > • @Inject : already there > > • @Qualifier : already there > > • Producers and disposers > > • Programatic lookup > > • Java SE Bootstrap > > When you say "The goal here is not to propose a new EE profile but a > subspec", 330 could already be seen as a subspec. If you put events > apparts, what would be missing in this list in your point of view ? And > what obstacles do you see in archieving this ? > > > > To boostrap CDI we have a CDIProvider, why not having an > InjectionProvider just to bootstrap 330 (then, CDIProvider could extend > InjectionProvider, so it bootstraps the all thing) ? > > > > Antonio > > > > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand < > antoine(a)sabot-durand.net&gt; wrote: > > Yes Arjan, I think it's the first reason. We really should work with > them to understand what should be added to CDI 2.0 to have it as a first > citizen DI in their spec. > > > > Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com&gt; a > écrit : > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > <antonio.goncalves(a)gmail.com&gt; wrote: > > > I remember talking with the JAX-RS guys (Java EE), years ago (back in > EE6), > > > and their answer for not adopting CDI was "too heavy". > > > > I can't find an exact reference anymore, but I somewhat remember that > > one of the reasons was also simply that CDI as a general solution > > finished late in Java EE 6, while JAX-RS finished earlier and had all > > the work for their own DI solution already done. > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -- 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>

Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a): > I don't see Events in a "Lite" version because the other DI frameworks > don't use them. A "fatter" 330 with producers, programmatic lookup and > bootstrap, could be "easily" implemented by Spring, Guice... If we leave > events in a Lite version, then it won't be the case, and Weld and OWB > will be the only two implementations. > > For me, a Lite version would just be about DI. If Weld uses events > internally to archieve basic DI, well, it's just an implementation > decision, not a spec. I would not even try to standardize the way > @Inject works (like Romain said, @Inject doesn't work the same in Weld > or Spring), let's leave it like this. > If you don't standardize how @Inject works then what's the purpose of having something like CDI Lite and many implementations which work differently? A user of implementation "A" will not be able to switch to implementation "B" easily. And that's one of the most important benefits of standardization... If you take back Antoine sentence > "/This would allow using CDI in constrained environment like mobile or > embedded devices/", then I don't think events would fit here. > > Antonio > > On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg(a)yahoo.de > <mailto:struberg@yahoo.de>> wrote: > > > For me, a Light version of CDI is clearly the features number. > That's why I don't see events in it. > > We did discuss this last year on the f2f meeting. The problem lies > within our Extension mechanism. Without events you also need to drop > the Extension mechanism. And to be honest, this is THE major hit in > all CDI… > Sorry to be the bad guy busting all those ideas. I really don’t want > to, but better now than too late down the road ;) > > It’s really tricky as many features are heavily based on each other. > E.g. by removing scanning you could get rid of javassist/asm/etc ? > nope, we also have our class proxies which need bytecode tinkering. > So remove interceptors and decorators too? Well yea, but we still > have normalscoping -> what is left? basically spring prototype and > singleton. Hmm. that’s not that much compared to full CDI. And all > that for only 200kByte? > (Btw we also discussed generating the bytecode classes at build > time, but then we still miss the dynamics we get from Extensions, > e.g. PAT adding an interceptor annotation) > Just to give you a rough idea how this all works together when it > comes to implementation details… > Please feel free to ask Jozef and me for further infos on > ‚dependencies‘. > > LieGrue, > strub > > > > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves > <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>>: > > > > For me, a Light version of CDI is clearly the features number. > That's why I don't see events in it. > > > > For me, a CDI Lite would just focus on DI. If CDI has @Produces > and Spring has @Bean, then it's because 330 lakes this functionality. > > > > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau > <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: > > Lite can have several definition, let's try to list them up if it > can help: > > > > - binary size: for me until 3M for an app it is "Lite" > > - features number: the whole IoC set of feature is light since > you almost always need it, it means you can do lighter but it > wouldnt be used - check spring, who uses only spring-ioc and not > context or more? > > - features complexity: sure we are not light here but supporting > scopes already breaks "Lite-ness" IMO so not a real issue > > > > So my view is CDI "SE" is light enough - as a spec and spec can't > affect implementations so seems the fight is not on the right side > to me. > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves > <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>>: > > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 > where he forked 330 because he found CDI was doing too much ;o) > > > > For me, "CDI Lite" was just basic dependency injection. The fact > that CDI can now run on SE (like JPA....), is good... but for me it > has nothing to do with Light : it's the entire thing that can > bootstrap in SE. Good. > > > > So what is Lite for you guys ? > > > > Antonio > > > > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau > <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: > > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com > <mailto:john.d.ament@gmail.com>>: > > Personally, I'm not in favor of a slimmed down runtime. It was > tried with EJB, but never implemented properly (most implementations > that support EJB-lite actually support the entire thing, except for > deprecated stuff). > > > > > > +1, most of CDI is basic and quickly any light version will miss > events or other thing - in particular in maintaining micro services > from experience. Size of an implementation can easily be < 1M so not > sure it would bring anything. Only important point is what Antoine > started to do ie ensuring EE and SE parts are clearly identified and > split in the spec. > > > > I think if we define SE properly we won't have a need for this. > > > > John > > > > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves > <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>> > wrote: > > @Antoine, so which content do you see in CDI Lite ? Are you sure > about events ? > > > > I'm in favor of a "fatter" 330 that would have : > > • @Inject : already there > > • @Qualifier : already there > > • Producers and disposers > > • Programatic lookup > > • Java SE Bootstrap > > When you say "The goal here is not to propose a new EE profile > but a subspec", 330 could already be seen as a subspec. If you put > events apparts, what would be missing in this list in your point of > view ? And what obstacles do you see in archieving this ? > > > > To boostrap CDI we have a CDIProvider, why not having an > InjectionProvider just to bootstrap 330 (then, CDIProvider could > extend InjectionProvider, so it bootstraps the all thing) ? > > > > Antonio > > > > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: > > Yes Arjan, I think it's the first reason. We really should work > with them to understand what should be added to CDI 2.0 to have it > as a first citizen DI in their spec. > > > > Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com > <mailto:arjan.tijms@gmail.com>> a écrit : > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > <antonio.goncalves(a)gmail.com > <mailto:antonio.goncalves@gmail.com>> wrote: > > > I remember talking with the JAX-RS guys (Java EE), years ago > (back in EE6), > > > and their answer for not adopting CDI was "too heavy". > > > > I can't find an exact reference anymore, but I somewhat remember > that > > one of the reasons was also simply that CDI as a general solution > > finished late in Java EE 6, while JAX-RS finished earlier and had > all > > the work for their own DI solution already done. > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > -- Martin Kouba Software Engineer Red Hat, Czech Republic

The way @Inject works is not specified in 330, and it's better to leave it like this, otherwise we will loose Spring and Guice as implementations.

Antonio On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> wrote: Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a): I don't see Events in a "Lite" version because the other DI frameworks don't use them. A "fatter" 330 with producers, programmatic lookup and bootstrap, could be "easily" implemented by Spring, Guice... If we leave events in a Lite version, then it won't be the case, and Weld and OWB will be the only two implementations. For me, a Lite version would just be about DI. If Weld uses events internally to archieve basic DI, well, it's just an implementation decision, not a spec. I would not even try to standardize the way @Inject works (like Romain said, @Inject doesn't work the same in Weld or Spring), let's leave it like this. If you don't standardize how @Inject works then what's the purpose of having something like CDI Lite and many implementations which work differently? A user of implementation "A" will not be able to switch to implementation "B" easily. And that's one of the most important benefits of standardization... If you take back Antoine sentence "/This would allow using CDI in constrained environment like mobile or embedded devices/", then I don't think events would fit here. Antonio On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de> <mailto:struberg@yahoo.de <mailto:struberg@yahoo.de>>> wrote: > For me, a Light version of CDI is clearly the features number. That's why I don't see events in it. We did discuss this last year on the f2f meeting. The problem lies within our Extension mechanism. Without events you also need to drop the Extension mechanism. And to be honest, this is THE major hit in all CDI… Sorry to be the bad guy busting all those ideas. I really don’t want to, but better now than too late down the road ;) It’s really tricky as many features are heavily based on each other. E.g. by removing scanning you could get rid of javassist/asm/etc ? nope, we also have our class proxies which need bytecode tinkering. So remove interceptors and decorators too? Well yea, but we still have normalscoping -> what is left? basically spring prototype and singleton. Hmm. that’s not that much compared to full CDI. And all that for only 200kByte? (Btw we also discussed generating the bytecode classes at build time, but then we still miss the dynamics we get from Extensions, e.g. PAT adding an interceptor annotation) Just to give you a rough idea how this all works together when it comes to implementation details… Please feel free to ask Jozef and me for further infos on ‚dependencies‘. LieGrue, strub > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com> <mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@gmail.com>>>: > > For me, a Light version of CDI is clearly the features number. That's why I don't see events in it. > > For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring has @Bean, then it's because 330 lakes this functionality. > > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com> <mailto:rmannibucau@gmail.com <mailto:rmannibucau@gmail.com>>> wrote: > Lite can have several definition, let's try to list them up if it can help: > > - binary size: for me until 3M for an app it is "Lite" > - features number: the whole IoC set of feature is light since you almost always need it, it means you can do lighter but it wouldnt be used - check spring, who uses only spring-ioc and not context or more? > - features complexity: sure we are not light here but supporting scopes already breaks "Lite-ness" IMO so not a real issue > > So my view is CDI "SE" is light enough - as a spec and spec can't affect implementations so seems the fight is not on the right side to me. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com> <mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@gmail.com>>>: > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he forked 330 because he found CDI was doing too much ;o) > > For me, "CDI Lite" was just basic dependency injection. The fact that CDI can now run on SE (like JPA....), is good... but for me it has nothing to do with Light : it's the entire thing that can bootstrap in SE. Good. > > So what is Lite for you guys ? > > Antonio > > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com> <mailto:rmannibucau@gmail.com <mailto:rmannibucau@gmail.com>>> wrote: > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com> <mailto:john.d.ament@gmail.com <mailto:john.d.ament@gmail.com>>>: > Personally, I'm not in favor of a slimmed down runtime. It was tried with EJB, but never implemented properly (most implementations that support EJB-lite actually support the entire thing, except for deprecated stuff). > > > +1, most of CDI is basic and quickly any light version will miss events or other thing - in particular in maintaining micro services from experience. Size of an implementation can easily be < 1M so not sure it would bring anything. Only important point is what Antoine started to do ie ensuring EE and SE parts are clearly identified and split in the spec. > > I think if we define SE properly we won't have a need for this. > > John > > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com> <mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@gmail.com>>> wrote: > @Antoine, so which content do you see in CDI Lite ? Are you sure about events ? > > I'm in favor of a "fatter" 330 that would have : > • @Inject : already there > • @Qualifier : already there > • Producers and disposers > • Programatic lookup > • Java SE Bootstrap > When you say "The goal here is not to propose a new EE profile but a subspec", 330 could already be seen as a subspec. If you put events apparts, what would be missing in this list in your point of view ? And what obstacles do you see in archieving this ? > > To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all thing) ? > > Antonio > > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net> <mailto:antoine@sabot-durand.net <mailto:antoine@sabot-durand.net>>> wrote: > Yes Arjan, I think it's the first reason. We really should work with them to understand what should be added to CDI 2.0 to have it as a first citizen DI in their spec. > > Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com <mailto:arjan.tijms@gmail.com> <mailto:arjan.tijms@gmail.com <mailto:arjan.tijms@gmail.com>>> a écrit : > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com> <mailto:antonio.goncalves@gmail.com <mailto:antonio.goncalves@gmail.com>>> wrote: > > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6), > > and their answer for not adopting CDI was "too heavy". > > I can't find an exact reference anymore, but I somewhat remember that > one of the reasons was also simply that CDI as a general solution > finished late in Java EE 6, while JAX-RS finished earlier and had all > the work for their own DI solution already done. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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. -- Martin Kouba Software Engineer Red Hat, Czech Republic -- 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>