[cdi-dev] Time to start working on CDI lite

Mon Aug 31 05:03:19 EDT 2015

Unless CDI 2 still ended up redefining the @Inject (aka JSR 330) standard
at least as MR, there is no change of that spec. So if it is free for
implementations to decide how @Inject works or if some (like Tapestry)
prefer their own parallel @Inject annotations side-by-side, that won't
change with a "CDI lite" profile or module.

Werner

On Mon, Aug 31, 2015 at 10:28 AM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at 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 (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 10:28:04 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Martin Kouba <mkouba at redhat.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CA+ZZq9-76Q8nug_q-uJmGTuxC9imzc9My2YHLHf7JoRmNZRCfA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 at 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 at yahoo.de
> >> <mailto:struberg at 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 at gmail.com <mailto:antonio.goncalves at 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 at gmail.com <mailto:rmannibucau at 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 at gmail.com <mailto:antonio.goncalves at 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 at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
> >>      > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
> >>     <mailto: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).
> >>      >
> >>      >
> >>      > +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 at gmail.com <mailto: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) ?
> >>      >
> >>      > Antonio
> >>      >
> >>      > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
> >>     <antoine at sabot-durand.net <mailto: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
> >>     <mailto:arjan.tijms at gmail.com>> a ?crit :
> >>      > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>      > <antonio.goncalves at gmail.com
> >>     <mailto:antonio.goncalves at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at 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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/639a074c/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 45
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/a6cca5be/attachment-0001.html 