[cdi-dev] Time to start working on CDI lite
antonio.goncalves at gmail.com
Sun Aug 30 09:40:29 EDT 2015
@John, I'm not mentioning any runtime here.
In Java EE, the "fatter" JSR 330 will get executed in a Java EE container,
as usual, no need extra runtime. On the other end, when I use WidlFly Swarm
to build some tiny services and I need basic injection, I need the full
CDI. What I'm saying is, with a fatter 330, Java SE will have basic
injection, but also Java EE. I know modularity is not in the EE roadmap for
now, but it will be. When it's the case, you will be able to say "I want a
Java EE app with basic injection" (and you will only get the 330 module) or
"I want the full thing" (and will get CDI, which depends on the fatter 330)
On Sun, Aug 30, 2015 at 3:22 PM, John D. Ament <john.d.ament at 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).
> I think if we define SE properly we won't have a need for this.
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at 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) ?
>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> antoine at 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 at gmail.com> a
>>> écrit :
>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>> <antonio.goncalves at gmail.com> wrote:
>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>>>> > 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 at lists.jboss.org
>> 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.
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> |
<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...
More information about the cdi-dev