[cdi-dev] Time to start working on CDI lite
Antoine Sabot-Durand
antoine at sabot-durand.net
Wed Sep 2 06:14:21 EDT 2015
Yes Werner
We are in discussion with the Aerogear team.
Antoine
Le mer. 2 sept. 2015 à 10:30, Romain Manni-Bucau <rmannibucau at gmail.com> a
écrit :
> 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.
>>
> _______________________________________________
> 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/8fa62f60/attachment-0001.html
More information about the cdi-dev
mailing list