Well if we found a way to offer some level of modularity and optionality
(despite SE or EE 8 not putting a strong emphasis on either yet) I would
certainly see it as an option. This could keep the size for some apps down
if they use other event systems already.
Werner
On Sun, Aug 30, 2015 at 9:11 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner(a)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)
----------------------------------------------------------------------
Message: 1
Date: Sun, 30 Aug 2015 21:11:24 +0200
From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
Subject: Re: [cdi-dev] Time to start working on CDI lite
To: Werner Keil <werner.keil(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<CACLE=
7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
> As there is well-established event handling on the SE and ME side, in
most
> cases based on java.util.EventObject, I could imagine CDI events being
> either outside a "lite" profile or at least optional, should we consider
> optionality.
>
>
not sure I agree, SE has an event hierarchy but its listener model is not
as usable as CDI most of the time because of the register side
> Werner
>
> On Sun, Aug 30, 2015 at 6:10 PM, <cdi-dev-request(a)lists.jboss.org>
wrote:
>
>> Send cdi-dev mailing list submissions to
>> cdi-dev(a)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(a)lists.jboss.org
>>
>> You can reach the person managing the list at
>> cdi-dev-owner(a)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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
>> 2. Re: Time to start working on CDI lite (Antonio Goncalves)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 2
>> Date: Sun, 30 Aug 2015 18:09:41 +0200
>> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Message-ID:
>> <CA+ZZq9-YFcTKuZr=+6v=
>> wH-w670E++qgBrN36DsToFEidUzenQ(a)mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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(a)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 <
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-30 15:57 GMT+02:00 Antonio Goncalves <
>> antonio.goncalves(a)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(a)gmail.com> wrote:
>> >>
>> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament
<john.d.ament(a)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(a)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(a)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(a)gmail.com
>
>> a
>> >>>>>> ?crit :
>> >>>>>>
>> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >>>>>>> <antonio.goncalves(a)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 <
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(a)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(a)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>
>> >>
>> >
>> >
>>
>>
>> --
>> 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/20150830/41058591/at...
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)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 35
>> ***************************************
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/717fde38/at...
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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 37
***************************************