3:22 a.m.
Forget about all the Android area for now. In android there are not
even
Annotations afaik. And Android is NOT Java. The runtime and all the
bytecode stuff we do here wont work that easily. So we would get rid of
TONS of neat stuff a >JavaSE app most of the times would LOVE to have.
This was still from Square's time, but shows at least @Qualifier or
@Module annotations (aside from the obvious @Override) so it looks like
some annotations do work for Android
https://github.com/square/dagger/tree/master/examples/android-simple
Can't speak for JBoss or Red Hat here, but at least their AeroGear native
libraries for Android https://aerogear.org/android/ speak a rather clear
language, and should any of CDI lite be usable to both Java SE and Android
I am sure, AeroGear would happily offer it there;-)
Werner
On Wed, Sep 2, 2015 at 10:04 AM, <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 (Mark Struberg)
2. F2F more information regarding the location (Antoine Sabot-Durand)
3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
support mode (Emily Jiang (JIRA))
4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
----------------------------------------------------------------------
Message: 1
Date: Mon, 31 Aug 2015 11:30:49 +0200
From: Mark Struberg <struberg(a)yahoo.de>
Subject: Re: [cdi-dev] Time to start working on CDI lite
To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de>
Content-Type: text/plain; charset=utf-8
>
> 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.
No, it?s not an impl thing at all but all the Extension events and it?s
usage are specified deep in the CDI spec.
Of course the impls could use different code parts for Extension events
and ?user events? but you still would need an event bus OR you would get
rid of Extensions alltogether. But that would be pretty insane imo ;)
There is also no need to go further in the JSR-330-only area. All CDI
containers must pass the atinject TCK and thus are fully certified JSR-330
containers as well. Add guice, Spring, picocontainer, etc to this. There is
really no need to go down even further in this road imo. We are not here
for world domination. We don?t need to do _every_ situation. Let?s instead
do OUR main goal really well.
> 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.
Forget about all the Android area for now. In android there are not even
Annotations afaik. And Android is NOT Java. The runtime and all the
bytecode stuff we do here wont work that easily. So we would get rid of
TONS of neat stuff a JavaSE app most of the times would LOVE to have.
IF we say that CDI-lite is targetting android then this is fine as well.
But then we aim for a TOTALLY different goal! This would not even be useful
in a SE. If you really like to have a lightweight-as-possible DI container,
such a project already exists. It is called Apache Avalon [1] and got
written in 1999. So it even predates Spring for about 5 years?
LieGrue,
strub
[1] https://en.wikipedia.org/wiki/Apache_Avalon
> Am 31.08.2015 um 09:57 schrieb Antonio Goncalves <
antonio.goncalves(a)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(a)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(a)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(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 | Blog | Github | LinkedIn | Tomitriber
> >
> > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > _______________________________________________
> > 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 | 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(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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
------------------------------
Message: 2
Date: Tue, 01 Sep 2015 12:04:12 +0000
From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
Subject: [cdi-dev] F2F more information regarding the location
To: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<
CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi guys,
I've updated the F2F sheet :
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
The tab location contains info for the event location and a suggested hotel
nearby.
Remember the community meeting will be on Friday 25th and Saturday 26th
Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150901/60e09a5e/at...
------------------------------
Message: 3
Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT)
From: "Emily Jiang (JIRA)" <issues(a)jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes
injection support mode
To: cdi-dev(a)lists.jboss.org
Message-ID:
<JIRA.12583475.1441127998000.11694.1441128005252(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
Emily Jiang created CDI-556:
-------------------------------
Summary: JavaEE component classes injection support mode
Key: CDI-556
URL: https://issues.jboss.org/browse/CDI-556
Project: CDI Specification Issues
Issue Type: Clarification
Components: Java EE integration
Affects Versions: 1.2.Final
Environment: all
Reporter: Emily Jiang
>From CDI 1.2 spec,
An archive which:
? contains a beans.xml file with the bean-discovery-mode of none, or,
? contains an extension and no beans.xml file
is not a bean archive.
Do JavaEE component classes support injections in the non bean archives?
The spec is not clear on this.
Jozef said:
Java EE spec states in "EE.5.2.5
Annotations and Injection":
"The component classes listed in Table EE.5-1 with support level Standard
all support Java EE resource injection, as well as PostConstruct and
PreDestroy callbacks. In addition, if CDI is enabled?which it is by
default?these classes also support CDI injection, as described in Section
EE.5.24, Support for Dependency Injection, and the use of interceptors."
However, it is not clear what "if CDI is enabled" means. One can argue
that "CDI is enabled" if the component class resides in a bean archive. The
other interpretation (the one I personally prefer) might be that "CDI is
enabled" if a CDI container is initialized for the application (i.e.
there's at least one CDI bean archive).
The CDI spec needs to be clear on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
------------------------------
Message: 4
Date: Wed, 2 Sep 2015 08:03:57 +0000
From: Notme <noreply(a)badoo.com>
Subject: [cdi-dev] ? Lies Deine Nachricht, bevor sie gel?scht wird!
To: cdi-dev(a)lists.jboss.org
Message-ID: <20150902080357.B35AB15C91362(a)cluster1040.monopost.com>
Content-Type: text/plain; charset="utf-8"
Lies Deine Nachricht von Notme, bevor sie gel?scht wird!
Um Deine Nachricht zu lesen, klicke bitte auf folgenden Link:
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
Einige der Nutzer in Deiner Gegend:
LizzyLou (Adliswil, Schweiz)
Sarah (Opfikon, Schweiz)
Marco (Opfikon, Schweiz)
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
Funktionieren die angegebenen Links nicht? Kopiere sie bitte in die
Adresszeile Deines Browsers.
Du erh?ltst diese Email aufgrund einer neuen Nachricht von Notme. Wenn Du
diese Email versehentlich erhalten hast, ignoriere sie bitte. Unser System
entfernt diese Nachricht nach einiger Zeit dann automatisch.
Viel Spa?!
Liebe Gr??e,
Dein Badoo Team
Du hast diese Email von Badoo Trading Limited (Postanschrift siehe unten)
erhalten. Wenn Du keine weiteren Emails von Badoo erhalten m?chtest, klick
bitte hier, um Dich aus unserem Verteiler entfernen zu lassen:
https://eu1.badoo.com/impersonation.phtml?lang_id=5&email=cdi-dev%40l...
.
Badoo Trading Limited ist ein Unternehmen mit beschr?nkter Haftung,
registriert in England und Wales unter CRN 7540255, mit dem eingetragenen
Firmensitz Media Village, 131 - 151 Great Titchfield Street, London, W1W
5BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/f312b6a9/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 58, Issue 1
**************************************
3:30 a.m.
New subject: Time to start working on CDI lite
2015-09-02 10:22 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
>Forget about all the Android area for now. In android there are
not even
Annotations afaik. And Android is NOT Java. The runtime and all the
bytecode stuff we do here wont work that easily. So we would get rid of
TONS of neat stuff a >JavaSE app most of the times would LOVE to have.
This was still from Square's time, but shows at least @Qualifier or
@Module annotations (aside from the obvious @Override) so it looks like
some annotations do work for Android
https://github.com/square/dagger/tree/master/examples/android-simple
Can't speak for JBoss or Red Hat here, but at least their AeroGear native
libraries for Android https://aerogear.org/android/ speak a rather clear
language, and should any of CDI lite be usable to both Java SE and Android
I am sure, AeroGear would happily offer it there;-)
Android supports all annotations you want while it doesnt hit the device
but the codegen phase during the *build* (http://androidannotations.org/
for instance). That is what does dagger AFAIK.
Werner
On Wed, Sep 2, 2015 at 10:04 AM, <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 (Mark Struberg)
> 2. F2F more information regarding the location (Antoine Sabot-Durand)
> 3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
> support mode (Emily Jiang (JIRA))
> 4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 11:30:49 +0200
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de>
> Content-Type: text/plain; charset=utf-8
>
> >
> > 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.
>
> No, it?s not an impl thing at all but all the Extension events and it?s
> usage are specified deep in the CDI spec.
> Of course the impls could use different code parts for Extension events
> and ?user events? but you still would need an event bus OR you would get
> rid of Extensions alltogether. But that would be pretty insane imo ;)
>
> There is also no need to go further in the JSR-330-only area. All CDI
> containers must pass the atinject TCK and thus are fully certified JSR-330
> containers as well. Add guice, Spring, picocontainer, etc to this. There is
> really no need to go down even further in this road imo. We are not here
> for world domination. We don?t need to do _every_ situation. Let?s instead
> do OUR main goal really well.
>
>
> > 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.
>
>
> Forget about all the Android area for now. In android there are not even
> Annotations afaik. And Android is NOT Java. The runtime and all the
> bytecode stuff we do here wont work that easily. So we would get rid of
> TONS of neat stuff a JavaSE app most of the times would LOVE to have.
>
>
> IF we say that CDI-lite is targetting android then this is fine as well.
> But then we aim for a TOTALLY different goal! This would not even be useful
> in a SE. If you really like to have a lightweight-as-possible DI container,
> such a project already exists. It is called Apache Avalon [1] and got
> written in 1999. So it even predates Spring for about 5 years?
>
> LieGrue,
> strub
>
> [1] https://en.wikipedia.org/wiki/Apache_Avalon
>
>
>
> > Am 31.08.2015 um 09:57 schrieb Antonio Goncalves <
> antonio.goncalves(a)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(a)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(a)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(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 | Blog | Github | LinkedIn | Tomitriber
> > >
> > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> > > _______________________________________________
> > > 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 | 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(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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 01 Sep 2015 12:04:12 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] F2F more information regarding the location
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> I've updated the F2F sheet :
>
>
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
>
> The tab location contains info for the event location and a suggested
> hotel
> nearby.
>
> Remember the community meeting will be on Friday 25th and Saturday 26th
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150901/60e09a5e/at...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT)
> From: "Emily Jiang (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes
> injection support mode
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12583475.1441127998000.11694.1441128005252(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
> Emily Jiang created CDI-556:
> -------------------------------
>
> Summary: JavaEE component classes injection support mode
> Key: CDI-556
> URL: https://issues.jboss.org/browse/CDI-556
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.2.Final
> Environment: all
> Reporter: Emily Jiang
>
>
> >From CDI 1.2 spec,
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file
> is not a bean archive.
>
> Do JavaEE component classes support injections in the non bean archives?
> The spec is not clear on this.
>
> Jozef said:
> Java EE spec states in "EE.5.2.5
> Annotations and Injection":
>
> "The component classes listed in Table EE.5-1 with support level Standard
> all support Java EE resource injection, as well as PostConstruct and
> PreDestroy callbacks. In addition, if CDI is enabled?which it is by
> default?these classes also support CDI injection, as described in Section
> EE.5.24, Support for Dependency Injection, and the use of interceptors."
>
> However, it is not clear what "if CDI is enabled" means. One can argue
> that "CDI is enabled" if the component class resides in a bean archive.
The
> other interpretation (the one I personally prefer) might be that "CDI is
> enabled" if a CDI container is initialized for the application (i.e.
> there's at least one CDI bean archive).
>
> The CDI spec needs to be clear on this.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 2 Sep 2015 08:03:57 +0000
> From: Notme <noreply(a)badoo.com>
> Subject: [cdi-dev] ? Lies Deine Nachricht, bevor sie gel?scht wird!
> To: cdi-dev(a)lists.jboss.org
> Message-ID: <20150902080357.B35AB15C91362(a)cluster1040.monopost.com>
> Content-Type: text/plain; charset="utf-8"
>
> Lies Deine Nachricht von Notme, bevor sie gel?scht wird!
>
> Um Deine Nachricht zu lesen, klicke bitte auf folgenden Link:
>
>
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
>
>
> Einige der Nutzer in Deiner Gegend:
> LizzyLou (Adliswil, Schweiz)
> Sarah (Opfikon, Schweiz)
> Marco (Opfikon, Schweiz)
>
>
>
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
>
>
> Funktionieren die angegebenen Links nicht? Kopiere sie bitte in die
> Adresszeile Deines Browsers.
>
>
> Du erh?ltst diese Email aufgrund einer neuen Nachricht von Notme. Wenn Du
> diese Email versehentlich erhalten hast, ignoriere sie bitte. Unser System
> entfernt diese Nachricht nach einiger Zeit dann automatisch.
>
>
> Viel Spa?!
>
>
> Liebe Gr??e,
> Dein Badoo Team
>
> Du hast diese Email von Badoo Trading Limited (Postanschrift siehe unten)
> erhalten. Wenn Du keine weiteren Emails von Badoo erhalten m?chtest, klick
> bitte hier, um Dich aus unserem Verteiler entfernen zu lassen:
>
https://eu1.badoo.com/impersonation.phtml?lang_id=5&email=cdi-dev%40l...
> .
> Badoo Trading Limited ist ein Unternehmen mit beschr?nkter Haftung,
> registriert in England und Wales unter CRN 7540255, mit dem eingetragenen
> Firmensitz Media Village, 131 - 151 Great Titchfield Street, London, W1W
> 5BB.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/f312b6a9/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 58, Issue 1
> **************************************
>
_______________________________________________
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.
5:14 a.m.
New subject: Time to start working on CDI lite
Yes Werner
We are in discussion with the Aerogear team.
Antoine
Le mer. 2 sept. 2015 à 10:30, Romain Manni-Bucau <rmannibucau(a)gmail.com> a
écrit :
2015-09-02 10:22 GMT+02:00 Werner Keil
<werner.keil(a)gmail.com>:
> >Forget about all the Android area for now. In android there are not even
> Annotations afaik. And Android is NOT Java. The runtime and all the
> bytecode stuff we do here wont work that easily. So we would get rid of
> TONS of neat stuff a >JavaSE app most of the times would LOVE to have.
>
> This was still from Square's time, but shows at least @Qualifier or
> @Module annotations (aside from the obvious @Override) so it looks like
> some annotations do work for Android
> https://github.com/square/dagger/tree/master/examples/android-simple
>
> Can't speak for JBoss or Red Hat here, but at least their AeroGear native
> libraries for Android https://aerogear.org/android/ speak a rather clear
> language, and should any of CDI lite be usable to both Java SE and Android
> I am sure, AeroGear would happily offer it there;-)
>
>
Android supports all annotations you want while it doesnt hit the device
but the codegen phase during the *build* (http://androidannotations.org/
for instance). That is what does dagger AFAIK.
> Werner
>
> On Wed, Sep 2, 2015 at 10:04 AM, <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 (Mark Struberg)
>> 2. F2F more information regarding the location (Antoine Sabot-Durand)
>> 3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
>> support mode (Emily Jiang (JIRA))
>> 4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 31 Aug 2015 11:30:49 +0200
>> From: Mark Struberg <struberg(a)yahoo.de>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de>
>> Content-Type: text/plain; charset=utf-8
>>
>> >
>> > 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.
>>
>> No, it?s not an impl thing at all but all the Extension events and it?s
>> usage are specified deep in the CDI spec.
>> Of course the impls could use different code parts for Extension events
>> and ?user events? but you still would need an event bus OR you would get
>> rid of Extensions alltogether. But that would be pretty insane imo ;)
>>
>> There is also no need to go further in the JSR-330-only area. All CDI
>> containers must pass the atinject TCK and thus are fully certified JSR-330
>> containers as well. Add guice, Spring, picocontainer, etc to this. There is
>> really no need to go down even further in this road imo. We are not here
>> for world domination. We don?t need to do _every_ situation. Let?s instead
>> do OUR main goal really well.
>>
>>
>> > 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.
>>
>>
>> Forget about all the Android area for now. In android there are not even
>> Annotations afaik. And Android is NOT Java. The runtime and all the
>> bytecode stuff we do here wont work that easily. So we would get rid of
>> TONS of neat stuff a JavaSE app most of the times would LOVE to have.
>>
>>
>> IF we say that CDI-lite is targetting android then this is fine as well.
>> But then we aim for a TOTALLY different goal! This would not even be useful
>> in a SE. If you really like to have a lightweight-as-possible DI container,
>> such a project already exists. It is called Apache Avalon [1] and got
>> written in 1999. So it even predates Spring for about 5 years?
>>
>> LieGrue,
>> strub
>>
>> [1] https://en.wikipedia.org/wiki/Apache_Avalon
>>
>>
>>
>> > Am 31.08.2015 um 09:57 schrieb Antonio Goncalves <
>> antonio.goncalves(a)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(a)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(a)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(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 | Blog | Github | LinkedIn | Tomitriber
>> > >
>> > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>> France
>> > > _______________________________________________
>> > > 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 | 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(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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 01 Sep 2015 12:04:12 +0000
>> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
>> Subject: [cdi-dev] F2F more information regarding the location
>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Message-ID:
>> <
>> CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi guys,
>>
>> I've updated the F2F sheet :
>>
>>
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
>>
>> The tab location contains info for the event location and a suggested
>> hotel
>> nearby.
>>
>> Remember the community meeting will be on Friday 25th and Saturday 26th
>>
>> Antoine
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>>
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150901/60e09a5e/at...
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT)
>> From: "Emily Jiang (JIRA)" <issues(a)jboss.org>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes
>> injection support mode
>> To: cdi-dev(a)lists.jboss.org
>> Message-ID:
>> <JIRA.12583475.1441127998000.11694.1441128005252(a)Atlassian.JIRA>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Emily Jiang created CDI-556:
>> -------------------------------
>>
>> Summary: JavaEE component classes injection support mode
>> Key: CDI-556
>> URL: https://issues.jboss.org/browse/CDI-556
>> Project: CDI Specification Issues
>> Issue Type: Clarification
>> Components: Java EE integration
>> Affects Versions: 1.2.Final
>> Environment: all
>> Reporter: Emily Jiang
>>
>>
>> >From CDI 1.2 spec,
>> An archive which:
>> ? contains a beans.xml file with the bean-discovery-mode of none, or,
>> ? contains an extension and no beans.xml file
>> is not a bean archive.
>>
>> Do JavaEE component classes support injections in the non bean archives?
>> The spec is not clear on this.
>>
>> Jozef said:
>> Java EE spec states in "EE.5.2.5
>> Annotations and Injection":
>>
>> "The component classes listed in Table EE.5-1 with support level
>> Standard all support Java EE resource injection, as well as PostConstruct
>> and PreDestroy callbacks. In addition, if CDI is enabled?which it is by
>> default?these classes also support CDI injection, as described in Section
>> EE.5.24, Support for Dependency Injection, and the use of interceptors."
>>
>> However, it is not clear what "if CDI is enabled" means. One can argue
>> that "CDI is enabled" if the component class resides in a bean archive.
The
>> other interpretation (the one I personally prefer) might be that "CDI is
>> enabled" if a CDI container is initialized for the application (i.e.
>> there's at least one CDI bean archive).
>>
>> The CDI spec needs to be clear on this.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.15#6346)
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 2 Sep 2015 08:03:57 +0000
>> From: Notme <noreply(a)badoo.com>
>> Subject: [cdi-dev] ? Lies Deine Nachricht, bevor sie gel?scht wird!
>> To: cdi-dev(a)lists.jboss.org
>> Message-ID: <20150902080357.B35AB15C91362(a)cluster1040.monopost.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Lies Deine Nachricht von Notme, bevor sie gel?scht wird!
>>
>> Um Deine Nachricht zu lesen, klicke bitte auf folgenden Link:
>>
>>
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
>>
>>
>> Einige der Nutzer in Deiner Gegend:
>> LizzyLou (Adliswil, Schweiz)
>> Sarah (Opfikon, Schweiz)
>> Marco (Opfikon, Schweiz)
>>
>>
>>
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
>>
>>
>> Funktionieren die angegebenen Links nicht? Kopiere sie bitte in die
>> Adresszeile Deines Browsers.
>>
>>
>> Du erh?ltst diese Email aufgrund einer neuen Nachricht von Notme. Wenn
>> Du diese Email versehentlich erhalten hast, ignoriere sie bitte. Unser
>> System entfernt diese Nachricht nach einiger Zeit dann automatisch.
>>
>>
>> Viel Spa?!
>>
>>
>> Liebe Gr??e,
>> Dein Badoo Team
>>
>> Du hast diese Email von Badoo Trading Limited (Postanschrift siehe
>> unten) erhalten. Wenn Du keine weiteren Emails von Badoo erhalten m?chtest,
>> klick bitte hier, um Dich aus unserem Verteiler entfernen zu lassen:
>>
https://eu1.badoo.com/impersonation.phtml?lang_id=5&email=cdi-dev%40l...
>> .
>> Badoo Trading Limited ist ein Unternehmen mit beschr?nkter Haftung,
>> registriert in England und Wales unter CRN 7540255, mit dem eingetragenen
>> Firmensitz Media Village, 131 - 151 Great Titchfield Street, London, W1W
>> 5BB.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>>
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/f312b6a9/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 58, Issue 1
>> **************************************
>>
>
>
> _______________________________________________
> 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.
5:55 a.m.
New subject: Time to start working on CDI lite
Oki, sorry, was too unprecise.
Yes, you can use compile time annotations. But you cannot use runtime annotations in
Android afaik.
Thus all the parsing, AnnotatedType stuff, etc would basically be pretty moot, right?
+1 for reaching out to the AeroGear team btw.
LieGrue,
strub
> Am 02.09.2015 um 10:30 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com>:
>
>
> 2015-09-02 10:22 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
> >Forget about all the Android area for now. In android there are not even
Annotations afaik. And Android is NOT Java. The runtime and all the bytecode stuff we do
here wont work that easily. So we would get rid of TONS of neat stuff a >JavaSE app
most of the times would LOVE to have.
>
> This was still from Square's time, but shows at least @Qualifier or @Module
annotations (aside from the obvious @Override) so it looks like some annotations do work
for Android
> https://github.com/square/dagger/tree/master/examples/android-simple
>
> Can't speak for JBoss or Red Hat here, but at least their AeroGear native
libraries for Android https://aerogear.org/android/ speak a rather clear language, and
should any of CDI lite be usable to both Java SE and Android I am sure, AeroGear would
happily offer it there;-)
>
>
> Android supports all annotations you want while it doesnt hit the device but the
codegen phase during the *build* (http://androidannotations.org/ for instance). That is
what does dagger AFAIK.
>
> Werner
>
> On Wed, Sep 2, 2015 at 10:04 AM, <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 (Mark Struberg)
> 2. F2F more information regarding the location (Antoine Sabot-Durand)
> 3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
> support mode (Emily Jiang (JIRA))
> 4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 11:30:49 +0200
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de>
> Content-Type: text/plain; charset=utf-8
>
> >
> > 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.
>
> No, it?s not an impl thing at all but all the Extension events and it?s usage are
specified deep in the CDI spec.
> Of course the impls could use different code parts for Extension events and ?user
events? but you still would need an event bus OR you would get rid of Extensions
alltogether. But that would be pretty insane imo ;)
>
> There is also no need to go further in the JSR-330-only area. All CDI containers must
pass the atinject TCK and thus are fully certified JSR-330 containers as well. Add guice,
Spring, picocontainer, etc to this. There is really no need to go down even further in
this road imo. We are not here for world domination. We don?t need to do _every_
situation. Let?s instead do OUR main goal really well.
>
>
> > 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.
>
>
> Forget about all the Android area for now. In android there are not even Annotations
afaik. And Android is NOT Java. The runtime and all the bytecode stuff we do here wont
work that easily. So we would get rid of TONS of neat stuff a JavaSE app most of the times
would LOVE to have.
>
>
> IF we say that CDI-lite is targetting android then this is fine as well. But then we
aim for a TOTALLY different goal! This would not even be useful in a SE. If you really
like to have a lightweight-as-possible DI container, such a project already exists. It is
called Apache Avalon [1] and got written in 1999. So it even predates Spring for about 5
years?
>
> LieGrue,
> strub
>
> [1] https://en.wikipedia.org/wiki/Apache_Avalon
>
>
>
> > Am 31.08.2015 um 09:57 schrieb Antonio Goncalves
<antonio.goncalves(a)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(a)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(a)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(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 | Blog | Github | LinkedIn | Tomitriber
> > >
> > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > > _______________________________________________
> > > 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 | 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(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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 01 Sep 2015 12:04:12 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] F2F more information regarding the location
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> I've updated the F2F sheet :
>
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
>
> The tab location contains info for the event location and a suggested hotel
> nearby.
>
> Remember the community meeting will be on Friday 25th and Saturday 26th
>
> Antoine
>
6:26 a.m.
New subject: Time to start working on CDI lite
Le 2 sept. 2015 12:55, "Mark Struberg" <struberg(a)yahoo.de> a écrit :
You can compute it at compile time. The point being it is ourside cdispec.
> +1 for reaching out to the AeroGear team btw.
> LieGrue,
> strub
> >
Am 02.09.2015 um 10:30 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com
>:
> > > > 2015-09-02 10:22 GMT+02:00
Werner Keil <werner.keil(a)gmail.com>:
> > >Forget about all the Android area for now. In android there are not
even Annotations afaik. And Android is NOT Java. The runtime and all the
bytecode stuff we do here wont work that easily. So we would get rid of
TONS of neat stuff a >JavaSE app most of the times would LOVE to have.
> > > This was still from Square's time, but shows at
least @Qualifier or
@Module annotations (aside from the obvious @Override) so it looks like
some annotations do work for Android
> > https://github.com/square/dagger/tree/master/examples/android-simple
> > > Can't speak for JBoss or Red Hat here, but at
least their AeroGear
native libraries for Android https://aerogear.org/android/ speak a rather
clear language, and should any of CDI lite be usable to both Java SE and
Android I am sure, AeroGear would happily offer it there;-)
> > > > Android supports all
annotations you want while it doesnt hit the
device but the codegen phase during the *build* (
http://androidannotations.org/ for instance). That is what does dagger
AFAIK.
> > > Werner
> > > On Wed, Sep 2, 2015 at 10:04 AM,
<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 (Mark
Struberg)
> > 2. F2F more information regarding the location (Antoine Sabot-Durand)
> > 3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
> > support mode (Emily Jiang (JIRA))
> > 4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
> > > >
----------------------------------------------------------------------
> > > Message: 1
> > Date: Mon, 31 Aug 2015 11:30:49 +0200
> > From: Mark Struberg <struberg(a)yahoo.de > >
Subject: Re: [cdi-dev] Time to start working on CDI lite
> > To: Antonio Goncalves <antonio.goncalves(a)gmail.com > > Cc: cdi-dev <cdi-dev(a)lists.jboss.org > > Message-ID:
<19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de > >
Content-Type: text/plain; charset=utf-8
> > > > >
> 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.
> > > No, it?s not an impl thing at all but all the
Extension events and it?s
usage are specified deep in the CDI spec.
> > There is also no need to go further in the
JSR-330-only area. All CDI
containers must pass the atinject TCK and thus are fully certified JSR-330
containers as well. Add guice, Spring, picocontainer, etc to this. There is
really no need to go down even further in this road imo. We are not here
for world domination. We don?t need to do _every_ situation. Let?s instead
do OUR main goal really well.
> > > > > 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.
> > > > Forget about all the
Android area for now. In android there are not
even Annotations afaik. And Android is NOT Java. The runtime and all the
bytecode stuff we do here wont work that easily. So we would get rid of
TONS of neat stuff a JavaSE app most of the times would LOVE to have.
> > > > IF we say that CDI-lite is
targetting android then this is fine as
well. But then we aim for a TOTALLY different goal! This would not even be
useful in a SE. If you really like to have a lightweight-as-possible DI
container, such a project already exists. It is called Apache Avalon [1]
and got written in 1999. So it even predates Spring for about 5 years?
> > > LieGrue,
> > strub
> > > [1] https://en.wikipedia.org/wiki/Apache_Avalon
> > > > >
> Am 31.08.2015 um 09:57 schrieb Antonio Goncalves <
antonio.goncalves(a)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(a)yahoo.de wrote:
> > > 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?
> > > 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?
> > > >
> LieGrue,
> > > strub
> > > > > > > > Am 30.08.2015 um 18:09 schrieb Antonio
Goncalves <
antonio.goncalves(a)gmail.com>:
> > > > > > > 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:
> > > > - 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?
> > > > 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(a)gmail.com>:
> > > > 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:
> > > > > > > +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:
> > > > 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:
> > > > 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
> > > > > > > >
> > --
> > > > Antonio Goncalves
> > > > Software architect, Java Champion and Pluralsight author
> > > > > > > Web site |
Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> > > > _______________________________________________
> > > > 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 |
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(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 | Twitter |
LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> > > > > > ------------------------------
> > > Message: 2
> > Date: Tue, 01 Sep 2015 12:04:12 +0000
> > From: Antoine Sabot-Durand <antoine(a)sabot-durand.net > > Subject: [cdi-dev] F2F more information regarding the
location
> > To: cdi-dev <cdi-dev(a)lists.jboss.org > >
Message-ID:
> > <
CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com > > Content-Type: text/plain; charset="utf-8"
> > > Hi guys,
> > > I've updated the F2F sheet :
>
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
> > > The tab location contains info for the event location
and a suggested
hotel
> > nearby.
> > > Remember the community meeting will be on Friday 25th
and Saturday 26th
> > > Antoine
> > ------------------------------
> > > Message: 3
> > Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT)
> > From: "Emily Jiang (JIRA)" <issues(a)jboss.org > > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE
component classes
> > injection support mode
> > To: cdi-dev(a)lists.jboss.org
> > Message-ID:
> > <JIRA.12583475.1441127998000.11694.1441128005252(a)Atlassian.JIRA > > Content-Type: text/plain; charset=UTF-8
> > > Emily Jiang created CDI-556:
> > -------------------------------
> > > Summary: JavaEE component classes
injection support mode
> > Key: CDI-556
> > URL: https://issues.jboss.org/browse/CDI-556
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Components: Java EE integration
> > Affects Versions: 1.2.Final
> > Environment: all
> > Reporter: Emily Jiang
> > > > >From CDI 1.2 spec,
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file
> > is not a bean archive.
> > > Do JavaEE component classes support injections in the
non bean
archives? The spec is not clear on this.
> > > Jozef said:
> > Java EE spec states in "EE.5.2.5
> > Annotations and Injection":
> > > "The component classes listed in Table EE.5-1
with support level
Standard all support Java EE resource injection, as well as PostConstruct
and PreDestroy callbacks. In addition, if CDI is enabled?which it is by
default?these classes also support CDI injection, as described in Section
EE.5.24, Support for Dependency Injection, and the use of interceptors."
> > > However, it is not clear what "if CDI is
enabled" means. One can argue
that "CDI is enabled" if the component class resides in a bean archive. The
other interpretation (the one I personally prefer) might be that "CDI is
enabled" if a CDI container is initialized for the application (i.e.
there's at least one CDI bean archive).
> > > The CDI spec needs to be clear on this.
> > > > >
--
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> > > > >
------------------------------
> > > Message: 4
> > Date: Wed, 2 Sep 2015 08:03:57 +0000
> > From: Notme <noreply(a)badoo.com > >
Subject: [cdi-dev] ? Lies Deine Nachricht, bevor sie gel?scht wird!
> > To: cdi-dev(a)lists.jboss.org
> > Message-ID: <20150902080357.B35AB15C91362(a)cluster1040.monopost.com > > Content-Type: text/plain; charset="utf-8"
> > > Lies Deine Nachricht von Notme, bevor sie gel?scht
wird!
> > > Um Deine Nachricht zu lesen, klicke bitte auf
folgenden Link:
>
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
> > > > Einige der Nutzer in
Deiner Gegend:
> > LizzyLou (Adliswil, Schweiz)
> > Sarah (Opfikon, Schweiz)
> > Marco (Opfikon, Schweiz)
> >
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-...
> > > > Funktionieren die
angegebenen Links nicht? Kopiere sie bitte in die
Adresszeile Deines Browsers.
> > > > Du erh?ltst diese Email
aufgrund einer neuen Nachricht von Notme. Wenn
Du diese Email versehentlich erhalten hast, ignoriere sie bitte. Unser
System entfernt diese Nachricht nach einiger Zeit dann automatisch.
> > > > Viel Spa?!
> > > > Liebe Gr??e,
> > Dein Badoo Team
> > > Du hast diese Email von Badoo Trading Limited
(Postanschrift siehe
unten) erhalten. Wenn Du keine weiteren Emails von Badoo erhalten m?chtest,
klick bitte hier, um Dich aus unserem Verteiler entfernen zu lassen:
https://eu1.badoo.com/impersonation.phtml?lang_id=5&email=cdi-dev%40l...
.
> > ------------------------------
> > > _______________________________________________
> > 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 58, Issue 1
> > **************************************
> > > >
_______________________________________________
> > 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.
Oki, sorry, was too unprecise.
Yes, you can use compile time annotations. But you cannot use runtime
annotations
in Android afaik.
Thus all the parsing, AnnotatedType stuff, etc would basically be
pretty
moot, right?
> Of course the impls could use different code parts for Extension
events
and ?user events? but you still would need an event bus OR you would get
rid of Extensions alltogether. But that would be pretty insane imo ;)
> > > > For me, a Light version of CDI is clearly the features
number.
That's why I don't see events in it.
> > > > 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 ;)
> > > > (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?.
> > > >
For me, a Light version of CDI is clearly the features number.
That's why I
don't see events in it.
> > > > > > Lite can have several definition, let's try to
list them up if it
can help:
> > > > > > - features complexity: sure we are not light here but
supporting
scopes already breaks "Lite-ness" IMO so not a real issue
> > > > > > 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)
> > > > > > 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).
> > > > > > @Antoine, so which content do you see in CDI Lite ?
Are you sure
about events ?
> > > > > > 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.
> > > > > > 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.
> > > > -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150901/60e09a5e/at...
> > Badoo Trading Limited ist ein Unternehmen mit beschr?nkter
Haftung,
registriert in England und Wales unter CRN 7540255, mit dem eingetragenen
Firmensitz Media Village, 131 - 151 Great Titchfield Street, London, W1W
5BB.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/f312b6a9/at...
>
9:45 a.m.
New subject: Time to start working on CDI lite
My argument was not about getting the info but what to do with it. It most times affects
our proxies.
I’ve now also found a small project called dexmaker which can create bytecode for the
dalvik VM on the fly
https://github.com/crittercism/dexmaker
I have no idea if this work with ART though.
If this turns out to work fine then we could even move full CDI to android.
But there are lots of experiments in front of us.
LieGrue,
strub
> Am 02.09.2015 um 13:26 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com>:
>
>
> Le 2 sept. 2015 12:55, "Mark Struberg" <struberg(a)yahoo.de> a écrit :
> >
> > Oki, sorry, was too unprecise.
> >
> > Yes, you can use compile time annotations. But you cannot use runtime
annotations in Android afaik.
> > Thus all the parsing, AnnotatedType stuff, etc would basically be pretty moot,
right?
> >
>
> You can compute it at compile time. The point being it is ourside cdispec.
>
> > +1 for reaching out to the AeroGear team btw.
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 02.09.2015 um 10:30 schrieb Romain Manni-Bucau
<rmannibucau(a)gmail.com>:
> > >
> > >
> > > 2015-09-02 10:22 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
> > > >Forget about all the Android area for now. In android there are not
even Annotations afaik. And Android is NOT Java. The runtime and all the bytecode stuff we
do here wont work that easily. So we would get rid of TONS of neat stuff a >JavaSE app
most of the times would LOVE to have.
> > >
> > > This was still from Square's time, but shows at least @Qualifier or
@Module annotations (aside from the obvious @Override) so it looks like some annotations
do work for Android
> > > https://github.com/square/dagger/tree/master/examples/android-simple
> > >
> > > Can't speak for JBoss or Red Hat here, but at least their AeroGear
native libraries for Android https://aerogear.org/android/ speak a rather clear language,
and should any of CDI lite be usable to both Java SE and Android I am sure, AeroGear would
happily offer it there;-)
> > >
> > >
> > > Android supports all annotations you want while it doesnt hit the device
but the codegen phase during the *build* (http://androidannotations.org/ for instance).
That is what does dagger AFAIK.
> > >
> > > Werner
> > >
> > > On Wed, Sep 2, 2015 at 10:04 AM, <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 (Mark Struberg)
> > > 2. F2F more information regarding the location (Antoine Sabot-Durand)
> > > 3. [JBoss JIRA] (CDI-556) JavaEE component classes injection
> > > support mode (Emily Jiang (JIRA))
> > > 4. ? Lies Deine Nachricht, bevor sie gel?scht wird! (Notme)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Mon, 31 Aug 2015 11:30:49 +0200
> > > From: Mark Struberg <struberg(a)yahoo.de>
> > > Subject: Re: [cdi-dev] Time to start working on CDI lite
> > > To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> > > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > > Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C(a)yahoo.de>
> > > Content-Type: text/plain; charset=utf-8
> > >
> > > >
> > > > 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.
> > >
> > > No, it?s not an impl thing at all but all the Extension events and it?s
usage are specified deep in the CDI spec.
> > > Of course the impls could use different code parts for Extension events and
?user events? but you still would need an event bus OR you would get rid of Extensions
alltogether. But that would be pretty insane imo ;)
> > >
> > > There is also no need to go further in the JSR-330-only area. All CDI
containers must pass the atinject TCK and thus are fully certified JSR-330 containers as
well. Add guice, Spring, picocontainer, etc to this. There is really no need to go down
even further in this road imo. We are not here for world domination. We don?t need to do
_every_ situation. Let?s instead do OUR main goal really well.
> > >
> > >
> > > > 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.
> > >
> > >
> > > Forget about all the Android area for now. In android there are not even
Annotations afaik. And Android is NOT Java. The runtime and all the bytecode stuff we do
here wont work that easily. So we would get rid of TONS of neat stuff a JavaSE app most of
the times would LOVE to have.
> > >
> > >
> > > IF we say that CDI-lite is targetting android then this is fine as well.
But then we aim for a TOTALLY different goal! This would not even be useful in a SE. If
you really like to have a lightweight-as-possible DI container, such a project already
exists. It is called Apache Avalon [1] and got written in 1999. So it even predates Spring
for about 5 years?
> > >
> > > LieGrue,
> > > strub
> > >
> > > [1] https://en.wikipedia.org/wiki/Apache_Avalon
> > >
> > >
> > >
> > > > Am 31.08.2015 um 09:57 schrieb Antonio Goncalves
<antonio.goncalves(a)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(a)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(a)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(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 | Blog | Github | LinkedIn | Tomitriber
> > > > >
> > > > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> > > > > _______________________________________________
> > > > > 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 | 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(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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> > >
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 2
> > > Date: Tue, 01 Sep 2015 12:04:12 +0000
> > > From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> > > Subject: [cdi-dev] F2F more information regarding the location
> > > To: cdi-dev <cdi-dev(a)lists.jboss.org>
> > > Message-ID:
> > >
<CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ(a)mail.gmail.com>
> > > Content-Type: text/plain; charset="utf-8"
> > >
> > > Hi guys,
> > >
> > > I've updated the F2F sheet :
> > >
https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcouml...
> > >
> > > The tab location contains info for the event location and a suggested
hotel
> > > nearby.
> > >
> > > Remember the community meeting will be on Friday 25th and Saturday 26th
> > >
> > > Antoine
> > >
3398
days inactive
3398
days old
5 comments
4 participants
participants (4)
-
Antoine Sabot-Durand -
Mark Struberg -
Romain Manni-Bucau -
Werner Keil