Werner
Send cdi-dev mailing list submissions to
cdi-dev@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@lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner@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@gmail.com>
Subject: Re: [cdi-dev] Time to start working on CDI lite
To: Antonio Goncalves <antonio.goncalves@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CACLE=7MzVcBrhnoeUpo6ZAMpDu_04SOWSttWc-hRJL4wm8vpDw@mail.gmail.com>
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@gmail.com>:
> 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@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@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@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@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@gmail.com> wrote:
>> > 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 | Twitter | LinkedIn | 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.
>> >
>> >
>> >
>> >
>> > --
>> > 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@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/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 31 Aug 2015 10:11:54 +0200
From: Martin Kouba <mkouba@redhat.com>
Subject: Re: [cdi-dev] Time to start working on CDI lite
To: Antonio Goncalves <antonio.goncalves@gmail.com>, Mark Struberg
<struberg@yahoo.de>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55E40C4A.4090905@redhat.com>
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@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@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@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@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@gmail.com <mailto:rmannibucau@gmail.com>> wrote:
> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament@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@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@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@gmail.com
> <mailto:arjan.tijms@gmail.com>> a ?crit :
> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> > <antonio.goncalves@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@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@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@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@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@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
***************************************