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