2015-08-30 15:22 GMT+02:00 John D. Ament <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@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@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@gmail.com> a écrit :
On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
<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 | TwitterLinkedIn | Pluralsight | Paris JUG | Devoxx France
_______________________________________________
cdi-dev mailing list
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@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.