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: Time to start working on CDI lite (Romain Manni-Bucau) 2. Re: Time to start working on CDI lite (Martin Kouba) ---------------------------------------------------------------------- Message: 1 Date: Mon, 31 Aug 2015 10:00:58 +0200 From: Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; Subject: Re: [cdi-dev] Time to start working on CDI lite To: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CACLE= 7MzVcBrhnoeUpo6ZAMpDu_04SOWSttWc-hRJL4wm8vpDw(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" @Antonio: spring and guice have events, they just dont work the same way CDI defined them but not a big deal IMO to support them (just one more processor for spring for instance). 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-31 9:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)gmail.com&gt;: > 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> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/4d1b9468/at... ------------------------------ Message: 2 Date: Mon, 31 Aug 2015 10:11:54 +0200 From: Martin Kouba <mkouba(a)redhat.com&gt; Subject: Re: [cdi-dev] Time to start working on CDI lite To: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt;, Mark Struberg <struberg(a)yahoo.de&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <55E40C4A.4090905(a)redhat.com&gt; Content-Type: text/plain; charset=windows-1252; format=flowed 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 ------------------------------ _______________________________________________ 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 57, Issue 43 ***************************************