[cdi-dev] Time to start working on CDI lite
Romain Manni-Bucau
rmannibucau at gmail.com
Wed Sep 2 04:30:20 EDT 2015
2015-09-02 10:22 GMT+02:00 Werner Keil <werner.keil at 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 at lists.jboss.org> wrote:
>
>> Send cdi-dev mailing list submissions to
>> cdi-dev at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>> cdi-dev-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>> cdi-dev-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Time to start working on CDI lite (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 at yahoo.de>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Antonio Goncalves <antonio.goncalves at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C at 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 at 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 at yahoo.de>
>> wrote:
>> > > For me, a Light version of CDI is clearly the features number. That's
>> why I don't see events in it.
>> >
>> > We did discuss this last year on the f2f meeting. The problem lies
>> within our Extension mechanism. Without events you also need to drop the
>> Extension mechanism. And to be honest, this is THE major hit in all CDI?
>> > Sorry to be the bad guy busting all those ideas. I really don?t want
>> to, but better now than too late down the road ;)
>> >
>> > It?s really tricky as many features are heavily based on each other.
>> E.g. by removing scanning you could get rid of javassist/asm/etc ? nope, we
>> also have our class proxies which need bytecode tinkering. So remove
>> interceptors and decorators too? Well yea, but we still have normalscoping
>> -> what is left? basically spring prototype and singleton. Hmm. that?s not
>> that much compared to full CDI. And all that for only 200kByte?
>> > (Btw we also discussed generating the bytecode classes at build time,
>> but then we still miss the dynamics we get from Extensions, e.g. PAT adding
>> an interceptor annotation)
>> > Just to give you a rough idea how this all works together when it comes
>> to implementation details?
>> > Please feel free to ask Jozef and me for further infos on
>> ?dependencies?.
>>
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <
>> antonio.goncalves at gmail.com>:
>> > >
>> > > For me, a Light version of CDI is clearly the features number. That's
>> why I don't see events in it.
>> > >
>> > > For me, a CDI Lite would just focus on DI. If CDI has @Produces and
>> Spring has @Bean, then it's because 330 lakes this functionality.
>> > >
>> > > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> > > Lite can have several definition, let's try to list them up if it can
>> help:
>> > >
>> > > - binary size: for me until 3M for an app it is "Lite"
>> > > - features number: the whole IoC set of feature is light since you
>> almost always need it, it means you can do lighter but it wouldnt be used -
>> check spring, who uses only spring-ioc and not context or more?
>> > > - features complexity: sure we are not light here but supporting
>> scopes already breaks "Lite-ness" IMO so not a real issue
>> > >
>> > > So my view is CDI "SE" is light enough - as a spec and spec can't
>> affect implementations so seems the fight is not on the right side to me.
>> > >
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>> > >
>> > > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
>> antonio.goncalves at gmail.com>:
>> > > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where
>> he forked 330 because he found CDI was doing too much ;o)
>> > >
>> > > For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI can now run on SE (like JPA....), is good... but for me it has nothing
>> to do with Light : it's the entire thing that can bootstrap in SE. Good.
>> > >
>> > > So what is Lite for you guys ?
>> > >
>> > > Antonio
>> > >
>> > > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> > > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> > > Personally, I'm not in favor of a slimmed down runtime. It was tried
>> with EJB, but never implemented properly (most implementations that support
>> EJB-lite actually support the entire thing, except for deprecated stuff).
>> > >
>> > >
>> > > +1, most of CDI is basic and quickly any light version will miss
>> events or other thing - in particular in maintaining micro services from
>> experience. Size of an implementation can easily be < 1M so not sure it
>> would bring anything. Only important point is what Antoine started to do ie
>> ensuring EE and SE parts are clearly identified and split in the spec.
>> > >
>> > > I think if we define SE properly we won't have a need for this.
>> > >
>> > > John
>> > >
>> > > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> antonio.goncalves at gmail.com> wrote:
>> > > @Antoine, so which content do you see in CDI Lite ? Are you sure
>> about events ?
>> > >
>> > > I'm in favor of a "fatter" 330 that would have :
>> > > ? @Inject : already there
>> > > ? @Qualifier : already there
>> > > ? Producers and disposers
>> > > ? Programatic lookup
>> > > ? Java SE Bootstrap
>> > > When you say "The goal here is not to propose a new EE profile but a
>> subspec", 330 could already be seen as a subspec. If you put events
>> apparts, what would be missing in this list in your point of view ? And
>> what obstacles do you see in archieving this ?
>> > >
>> > > To boostrap CDI we have a CDIProvider, why not having an
>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>> InjectionProvider, so it bootstraps the all thing) ?
>> > >
>> > > Antonio
>> > >
>> > > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> antoine at sabot-durand.net> wrote:
>> > > Yes Arjan, I think it's the first reason. We really should work with
>> them to understand what should be added to CDI 2.0 to have it as a first
>> citizen DI in their spec.
>> > >
>> > > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>> ?crit :
>>
>> > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> > > <antonio.goncalves at gmail.com> wrote:
>> > > > I remember talking with the JAX-RS guys (Java EE), years ago (back
>> in EE6),
>> > > > and their answer for not adopting CDI was "too heavy".
>> > >
>> > > I can't find an exact reference anymore, but I somewhat remember that
>> > > one of the reasons was also simply that CDI as a general solution
>> > > finished late in Java EE 6, while JAX-RS finished earlier and had all
>> > > the work for their own DI solution already done.
>> > >
>> > >
>> > >
>> > > --
>> > > Antonio Goncalves
>> > > Software architect, Java Champion and Pluralsight author
>> > >
>> > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>> France
>> > > _______________________________________________
>> > > cdi-dev mailing list
>> > > cdi-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> > >
>> > > Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>> > >
>> > > _______________________________________________
>> > > cdi-dev mailing list
>> > > cdi-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> > >
>> > > Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Antonio Goncalves
>> > > Software architect, Java Champion and Pluralsight author
>> > >
>> > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>> France
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Antonio Goncalves
>> > > Software architect, Java Champion and Pluralsight author
>> > >
>> > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>> France
>> > > _______________________________________________
>> > > cdi-dev mailing list
>> > > cdi-dev at lists.jboss.org
>> > > 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 at sabot-durand.net>
>> Subject: [cdi-dev] F2F more information regarding the location
>> To: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>> <
>> CABu-YBTubzLZ3+SRq++dJ+fM21_rodTsL6zK_c-GPr7TsDMpGQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi guys,
>>
>> I've updated the F2F sheet :
>>
>> https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing
>>
>> 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/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT)
>> From: "Emily Jiang (JIRA)" <issues at jboss.org>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes
>> injection support mode
>> To: cdi-dev at lists.jboss.org
>> Message-ID:
>> <JIRA.12583475.1441127998000.11694.1441128005252 at 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 at badoo.com>
>> Subject: [cdi-dev] ? Lies Deine Nachricht, bevor sie gel?scht wird!
>> To: cdi-dev at lists.jboss.org
>> Message-ID: <20150902080357.B35AB15C91362 at 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-0-4&m=65&mid=55e6ad6c000000000005004d05f71a6c03e99e830000
>>
>>
>> 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-1-4&m=65&mid=55e6ad6c000000000005004d05f71a6c03e99e830000
>>
>>
>> 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%40lists.jboss.org&block_code=9765ba&m=65&mid=55e6ad6c000000000005004d05f71a6c03e99e830000&g=0-0-4
>> .
>> 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/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>> End of cdi-dev Digest, Vol 58, Issue 1
>> **************************************
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/28ca5f3e/attachment-0001.html
More information about the cdi-dev
mailing list