Android supports all annotations you want while it doesnt hit the device
but the codegen phase during the *build* (
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.