From antoine at sabot-durand.net Tue Sep 1 08:04:12 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 01 Sep 2015 12:04:12 +0000 Subject: [cdi-dev] F2F more information regarding the location Message-ID: 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.html From issues at jboss.org Tue Sep 1 13:20:05 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 1 Sep 2015 13:20:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes injection support mode In-Reply-To: References: Message-ID: 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) From noreply at badoo.com Wed Sep 2 04:03:57 2015 From: noreply at badoo.com (Notme) Date: Wed, 2 Sep 2015 08:03:57 +0000 Subject: [cdi-dev] =?utf-8?q?=E2=98=85_Lies_Deine_Nachricht=2C_bevor_sie_g?= =?utf-8?q?el=C3=B6scht_wird!?= Message-ID: <20150902080357.B35AB15C91362@cluster1040.monopost.com> 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-0001.html From werner.keil at gmail.com Wed Sep 2 04:22:10 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 2 Sep 2015 10:22:10 +0200 Subject: [cdi-dev] Time to start working on CDI lite Message-ID: >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, 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 > Subject: Re: [cdi-dev] Time to start working on CDI lite > To: Antonio Goncalves > Cc: cdi-dev > 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 > 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 : > > > 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 a > ?crit : > > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > > 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 > Subject: [cdi-dev] F2F more information regarding the location > To: cdi-dev > 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)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > injection support mode > To: cdi-dev at lists.jboss.org > Message-ID: > > 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 > 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 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/95834a68/attachment-0001.html From rmannibucau at gmail.com Wed Sep 2 04:30:20 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 2 Sep 2015 10:30:20 +0200 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: Message-ID: 2015-09-02 10:22 GMT+02:00 Werner Keil : > >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, 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 >> Subject: Re: [cdi-dev] Time to start working on CDI lite >> To: Antonio Goncalves >> Cc: cdi-dev >> 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 >> 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 : >> > > 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 a >> ?crit : >> >> > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >> > > 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 >> Subject: [cdi-dev] F2F more information regarding the location >> To: cdi-dev >> 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)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes >> injection support mode >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> 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 >> 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 From werner.keil at gmail.com Wed Sep 2 04:42:15 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 2 Sep 2015 10:42:15 +0200 Subject: [cdi-dev] F2F more information regarding the location Message-ID: Hi Antoine/all, So the F2F is only 2 days now, or what's the "non community day"? Must be RH-internal I suppose. I have to see, if Saturday is worth it, also based on agenda items being fleshed out (and travel or accomodation costs) So far Mark who referred to last year's F2F doesn't seem to come from "a bit further East" than myself it seems? While I did not see him as speaker for ApacheCon in Budapest, he probably goes there since it isn't as far, so some, especially EG Member and fellow speaker Anatole should be in Budapest less than a week later, too. Werner On Wed, Sep 2, 2015 at 10:04 AM, 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: 2 > Date: Tue, 01 Sep 2015 12:04:12 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] F2F more information regarding the location > To: cdi-dev > 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)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > injection support mode > To: cdi-dev at lists.jboss.org > Message-ID: > > 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 > 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 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150902/676be642/attachment.html From antoine at sabot-durand.net Wed Sep 2 04:47:14 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 02 Sep 2015 08:47:14 +0000 Subject: [cdi-dev] F2F more information regarding the location In-Reply-To: References: Message-ID: Werner, The community meeting was always planned on 2 days. FYI it was only one day last year and some EG members complained that this day was in the middle of the week, forcing them to take one day off. That's the reason why we choose Friday and Saturday for this meeting. It will be easier for independent contractor to take their Friday and if they can't they still have the Saturday (and stay one more day in Paris on Sunday if they wish) Antoine Le mer. 2 sept. 2015 ? 10:42, Werner Keil a ?crit : > Hi Antoine/all, > > So the F2F is only 2 days now, or what's the "non community day"? Must be > RH-internal I suppose. I have to see, if Saturday is worth it, also based > on agenda items being fleshed out (and travel or accomodation costs) > > So far Mark who referred to last year's F2F doesn't seem to come from "a > bit further East" than myself it seems? > While I did not see him as speaker for ApacheCon in Budapest, he probably > goes there since it isn't as far, so some, especially EG Member and fellow > speaker Anatole should be in Budapest less than a week later, too. > > Werner > > On Wed, Sep 2, 2015 at 10:04 AM, 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: 2 >> Date: Tue, 01 Sep 2015 12:04:12 +0000 >> From: Antoine Sabot-Durand >> Subject: [cdi-dev] F2F more information regarding the location >> To: cdi-dev >> 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)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes >> injection support mode >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> 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 >> 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/fb11fabe/attachment-0001.html From antoine at sabot-durand.net Wed Sep 2 06:14:21 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 02 Sep 2015 10:14:21 +0000 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: Message-ID: Yes Werner We are in discussion with the Aerogear team. Antoine Le mer. 2 sept. 2015 ? 10:30, Romain Manni-Bucau a ?crit : > 2015-09-02 10:22 GMT+02:00 Werner Keil : > >> >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, 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 >>> Subject: Re: [cdi-dev] Time to start working on CDI lite >>> To: Antonio Goncalves >>> Cc: cdi-dev >>> 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 >>> 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 : >>> > > 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 a >>> ?crit : >>> >>> > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves >>> > > 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 >>> Subject: [cdi-dev] F2F more information regarding the location >>> To: cdi-dev >>> 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)" >>> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes >>> injection support mode >>> To: cdi-dev at lists.jboss.org >>> Message-ID: >>> >>> 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 >>> 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 From mkouba at redhat.com Wed Sep 2 06:18:35 2015 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 2 Sep 2015 12:18:35 +0200 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: <47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de> <55E40C4A.4090905@redhat.com> Message-ID: <55E6CCFB.1080802@redhat.com> Dne 31.8.2015 v 10:28 Antonio Goncalves napsal(a): > The way @Inject works is not specified in 330, and it's better to leave > it like this, otherwise we will loose Spring and Guice as implementations. Yes, it's not. I'm afraid I'm lost in translation then. I will have to read the thread again ;-) > > Antonio > > On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba > wrote: > > Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a): > > 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 don't standardize how @Inject works then what's the purpose > of having something like CDI Lite and many implementations which > work differently? A user of implementation "A" will not be able to > switch to implementation "B" easily. And that's one of the most > important benefits of standardization... > > 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 > > >> 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 > > >>: > > > > 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 > > >> > 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 > > >>: > > 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 > > >> > wrote: > > 2015-08-30 15:22 GMT+02:00 John D. Ament > > >>: > > 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 > > >> > 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 > > >> 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 > > >> a ?crit : > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > > >> 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 > > > > _______________________________________________ > 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. > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | > Paris JUG | Devoxx France -- Martin Kouba Software Engineer Red Hat, Czech Republic From struberg at yahoo.de Wed Sep 2 06:55:02 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 2 Sep 2015 12:55:02 +0200 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: Message-ID: 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 : > > > 2015-09-02 10:22 GMT+02:00 Werner Keil : > >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, 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 > Subject: Re: [cdi-dev] Time to start working on CDI lite > To: Antonio Goncalves > Cc: cdi-dev > 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 : > > > > 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 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 : > > > > > > 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 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 : > > > 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 wrote: > > > 2015-08-30 15:22 GMT+02:00 John D. Ament : > > > 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 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 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 a ?crit : > > > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > > 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 > Subject: [cdi-dev] F2F more information regarding the location > To: cdi-dev > Message-ID: > > 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)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > injection support mode > To: cdi-dev at lists.jboss.org > Message-ID: > > 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 > 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. From rmannibucau at gmail.com Wed Sep 2 07:26:07 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 2 Sep 2015 13:26:07 +0200 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: Message-ID: Le 2 sept. 2015 12:55, "Mark Struberg" 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 : > > > > > > 2015-09-02 10:22 GMT+02:00 Werner Keil : > > >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, 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 > > Subject: Re: [cdi-dev] Time to start working on CDI lite > > To: Antonio Goncalves > > Cc: cdi-dev > > 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 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 : > > > > 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 a ?crit : > > > > > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > > > 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 > > Subject: [cdi-dev] F2F more information regarding the location > > To: cdi-dev > > 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)" > > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > > injection support mode > > To: cdi-dev at lists.jboss.org > > Message-ID: > > > > 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 > > 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/dd297da2/attachment-0001.html From nigel.deakin at oracle.com Wed Sep 2 10:33:28 2015 From: nigel.deakin at oracle.com (Nigel Deakin) Date: Wed, 2 Sep 2015 15:33:28 +0100 Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages In-Reply-To: <55DB4692.7040304@oracle.com> References: <55DB4692.7040304@oracle.com> Message-ID: <55E708B8.2090101@oracle.com> On 24/08/2015 17:30, Nigel Deakin wrote: > Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE > application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would become > a mandatory part of a full Java EE 8 application server. > > I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners > and send comments or questions to me or to the public users at jms-spec.java.net alias. Thank you for the feedback so far, which has been very helpful. I've also received some very helpful comments from the JMS expert group and community If you planned to make comments but haven't got round to doing so, your feedback would still be appreciated. I've attempted to record all the comments made so far on a wiki page. This is at https://java.net/projects/jms-spec/pages/CDIListenerBeanComments Here's a summary of the comments so far: * Is there a way to avoid the application having to inject and instantiate the listener bean? See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#Creating_listener_beans_automatically * Is there a way for the queue, message selector etc to be specified at runtime rather than hardcoded as an annotation? See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#Runtime_customisation * It might be desirable to allow JMS listener beans to listen to temporary queues and topics. See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#Listening_to_temporary_queues_and_topics * It's important that my application deploys even if the JMS provider isn't fully available yet See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#Handling_failures * What scopes are active when the callback method is invoked? See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#What_scopes_are_active_when_the_callback_method_is_invoked? * I think we should leverage the existing CDI event/observer functionality instead of introducing a completely new delivery mechanism See https://java.net/projects/jms-spec/pages/CDIListenerBeanComments#Are_CDI_events_better? Please feel free to make comments on those comments, or to raise new comments. Nigel From struberg at yahoo.de Wed Sep 2 10:45:38 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 2 Sep 2015 16:45:38 +0200 Subject: [cdi-dev] Time to start working on CDI lite In-Reply-To: References: Message-ID: 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 : > > > Le 2 sept. 2015 12:55, "Mark Struberg" 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 : > > > > > > > > > 2015-09-02 10:22 GMT+02:00 Werner Keil : > > > >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, 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 > > > Subject: Re: [cdi-dev] Time to start working on CDI lite > > > To: Antonio Goncalves > > > Cc: cdi-dev > > > 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 : > > > > > > > > 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 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 : > > > > > > > > > > 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 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 : > > > > > 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 wrote: > > > > > 2015-08-30 15:22 GMT+02:00 John D. Ament : > > > > > 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 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 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 a ?crit : > > > > > > > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves > > > > > 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 > > > Subject: [cdi-dev] F2F more information regarding the location > > > To: cdi-dev > > > Message-ID: > > > > > > 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)" > > > Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > > > injection support mode > > > To: cdi-dev at lists.jboss.org > > > Message-ID: > > > > > > 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 > > > 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. > > From issues at jboss.org Fri Sep 4 04:26:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 4 Sep 2015 04:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method In-Reply-To: References: Message-ID: Tomas Remes created CDI-557: ------------------------------- Summary: Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method Key: CDI-557 URL: https://issues.jboss.org/browse/CDI-557 Project: CDI Specification Issues Issue Type: Bug Reporter: Tomas Remes Priority: Minor http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata In paragraph for isAsync method there is: {quote} isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. {quote} AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 4 06:41:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Fri, 4 Sep 2015 06:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105531#comment-13105531 ] Emily Jiang commented on CDI-557: --------------------------------- I was going to report this as well. > Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method > ---------------------------------------------------------------------------- > > Key: CDI-557 > URL: https://issues.jboss.org/browse/CDI-557 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Priority: Minor > > http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata > In paragraph for isAsync method there is: > {quote} > isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. > {quote} > AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antonio.goncalves at gmail.com Mon Sep 7 05:04:00 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 7 Sep 2015 11:04:00 +0200 Subject: [cdi-dev] F2F more information regarding the location In-Reply-To: References: Message-ID: Hi all, As this face2face is being held in Paris, any plan to go to a restaurant to have diner on Friday or Saturday night ? Some might go back home on Saturday, so maybe Friday. WDYT ? Antonio On Wed, Sep 2, 2015 at 10:47 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Werner, > > The community meeting was always planned on 2 days. FYI it was only one > day last year and some EG members complained that this day was in the > middle of the week, forcing them to take one day off. That's the reason why > we choose Friday and Saturday for this meeting. It will be easier for > independent contractor to take their Friday and if they can't they still > have the Saturday (and stay one more day in Paris on Sunday if they wish) > > Antoine > > Le mer. 2 sept. 2015 ? 10:42, Werner Keil a > ?crit : > >> Hi Antoine/all, >> >> So the F2F is only 2 days now, or what's the "non community day"? Must be >> RH-internal I suppose. I have to see, if Saturday is worth it, also based >> on agenda items being fleshed out (and travel or accomodation costs) >> >> So far Mark who referred to last year's F2F doesn't seem to come from "a >> bit further East" than myself it seems? >> While I did not see him as speaker for ApacheCon in Budapest, he probably >> goes there since it isn't as far, so some, especially EG Member and fellow >> speaker Anatole should be in Budapest less than a week later, too. >> >> Werner >> >> On Wed, Sep 2, 2015 at 10:04 AM, 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: 2 >>> Date: Tue, 01 Sep 2015 12:04:12 +0000 >>> From: Antoine Sabot-Durand >>> Subject: [cdi-dev] F2F more information regarding the location >>> To: cdi-dev >>> 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)" >>> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes >>> injection support mode >>> To: cdi-dev at lists.jboss.org >>> Message-ID: >>> >>> 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 >>> 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150907/d84be5e6/attachment-0001.html From werner.keil at gmail.com Mon Sep 7 05:10:46 2015 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 7 Sep 2015 11:10:46 +0200 Subject: [cdi-dev] F2F more information regarding the location Message-ID: Antonio, Thanks for the update. I am waiting for the exact agenda, but I would not be able to join before Sat. If some leave on Sat or it is fairly short that day, I may not take the ride. If I do, I probably won't be in Paris yet before later in the evening, depending on train connections from Bern. Werner On Mon, Sep 7, 2015 at 11:04 AM, 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. [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata > interface" mentions fireAsyncEvent method (Emily Jiang (JIRA)) > 2. Re: F2F more information regarding the location > (Antonio Goncalves) > > > ---------------------------------------------------------------------- > > Message: 2 > Date: Mon, 7 Sep 2015 11:04:00 +0200 > From: Antonio Goncalves > Subject: Re: [cdi-dev] F2F more information regarding the location > To: cdi-dev > Message-ID: > ZY4eTdj0HMV9qG_JHWbuYBpHimR_kJj6aFQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > As this face2face is being held in Paris, any plan to go to a restaurant to > have diner on Friday or Saturday night ? Some might go back home on > Saturday, so maybe Friday. > > WDYT ? > > Antonio > > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 2 > >>> Date: Tue, 01 Sep 2015 12:04:12 +0000 > >>> From: Antoine Sabot-Durand > >>> Subject: [cdi-dev] F2F more information regarding the location > >>> To: cdi-dev > >>> 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)" > >>> Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes > >>> injection support mode > >>> To: cdi-dev at lists.jboss.org > >>> Message-ID: > >>> > > >>> 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 > >>> 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. > > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn < > http://www.linkedin.com/in/agoncal> | > Pluralsight > | > Paris > JUG | Devoxx France > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150907/d84be5e6/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 9 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150907/36c35f4f/attachment.html From EMIJIANG at uk.ibm.com Mon Sep 7 08:38:43 2015 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Mon, 7 Sep 2015 13:38:43 +0100 Subject: [cdi-dev] F2F more information regarding the location In-Reply-To: References: Message-ID: <201509071239.t87Cda9N028231@d06av04.portsmouth.uk.ibm.com> +1. Friday night is good for me. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server Liberty Profile development, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antonio Goncalves To: cdi-dev , Date: 07/09/2015 10:39 Subject: Re: [cdi-dev] F2F more information regarding the location Sent by: cdi-dev-bounces at lists.jboss.org Hi all, As this face2face is being held in Paris, any plan to go to a restaurant to have diner on Friday or Saturday night ? Some might go back home on Saturday, so maybe Friday. WDYT ? Antonio On Wed, Sep 2, 2015 at 10:47 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: Werner, The community meeting was always planned on 2 days. FYI it was only one day last year and some EG members complained that this day was in the middle of the week, forcing them to take one day off. That's the reason why we choose Friday and Saturday for this meeting. It will be easier for independent contractor to take their Friday and if they can't they still have the Saturday (and stay one more day in Paris on Sunday if they wish) Antoine Le mer. 2 sept. 2015 ? 10:42, Werner Keil a ?crit : Hi Antoine/all, So the F2F is only 2 days now, or what's the "non community day"? Must be RH-internal I suppose. I have to see, if Saturday is worth it, also based on agenda items being fleshed out (and travel or accomodation costs) So far Mark who referred to last year's F2F doesn't seem to come from "a bit further East" than myself it seems? While I did not see him as speaker for ApacheCon in Budapest, he probably goes there since it isn't as far, so some, especially EG Member and fellow speaker Anatole should be in Budapest less than a week later, too. Werner On Wed, Sep 2, 2015 at 10:04 AM, 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: 2 Date: Tue, 01 Sep 2015 12:04:12 +0000 From: Antoine Sabot-Durand Subject: [cdi-dev] F2F more information regarding the location To: cdi-dev 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)" Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes injection support mode To: cdi-dev at lists.jboss.org Message-ID: 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 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. -- 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150907/5e56e037/attachment-0001.html From issues at jboss.org Tue Sep 8 03:49:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 03:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106167#comment-13106167 ] Martin Kouba commented on CDI-519: ---------------------------------- bq. 2. to explicitly state that Instance can be used to destroy any dependent scoped bean instance of T. I'm not sure this is doable. A dependent bean instance doesn't know the object it depends on. That's what {{CreationalContext}} is for. bq. In your example if we go for 1, there will be no solution to destroy the instance you requested thru CDI. Well, it is. But it's not so easy to implement and also not 100% reliable (see WELD-1917 for more info how this is solved in Weld 2.2.11+). Moreover, it's not clear in the spec - e.g. the {{CDI.current()}} contract does not state anything about the identity of the CDI instance you get and whether it should be possible to use it to destroy any bean instance. > Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object > ------------------------------------------------------------------------------------------------------ > > Key: CDI-519 > URL: https://issues.jboss.org/browse/CDI-519 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > 5.6.1. The Instance interface: > {quote} > The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or... > {quote} > I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec: > {code:java} > @Dependent > class Bar { > } > class Foo { > @Inject > Instance instance; > void ping() { > instance.destroy(CDI.current().select(Bar.class).get()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 04:03:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 04:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the BeanBuilder API In-Reply-To: References: Message-ID: Martin Kouba created CDI-558: -------------------------------- Summary: Standardize the BeanBuilder API Key: CDI-558 URL: https://issues.jboss.org/browse/CDI-558 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 04:30:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 04:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-556) JavaEE component classes injection support mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106178#comment-13106178 ] Martin Kouba commented on CDI-556: ---------------------------------- I think we should also raise a Java EE spec issue on this. > 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.4.11#64026) From issues at jboss.org Tue Sep 8 04:55:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 04:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-19) Ordering execution on Extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106188#comment-13106188 ] Martin Kouba commented on CDI-19: --------------------------------- I believe this should be resolved as *rejected*. The ordering of container lifecycle events should work in CDI 2.0 EDR1 and the original feature request does not seem to be valid. > Ordering execution on Extensions > -------------------------------- > > Key: CDI-19 > URL: https://issues.jboss.org/browse/CDI-19 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Robson Ximenes > Priority: Minor > Fix For: 2.0 (discussion) > > > I believe the cdi portable extension could have the load order of extensions the same as it is registered; > It is possible that one extension expect some previous preparation of beans from another extension -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 05:05:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 05:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106197#comment-13106197 ] Martin Kouba commented on CDI-21: --------------------------------- +1 for BeforeBeanDiscovery. Only a CDI container is allowed to fire container lifecycle events (see also 10.2.1. The Event interface) and so it is safe to assume the event will only be delivered once. > Support PostConstruct callbacks in Extension class > -------------------------------------------------- > > Key: CDI-21 > URL: https://issues.jboss.org/browse/CDI-21 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Sivakumar Thyagarajan > Priority: Minor > Fix For: 2.0 (discussion) > > > It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification. > Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 05:26:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 05:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003430#comment-13003430 ] Martin Kouba edited comment on CDI-45 at 9/8/15 5:25 AM: --------------------------------------------------------- I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation. +1 for introducing a new convenient method {{Instance.isResolvable()}} (or any other better name). was (Author: mkouba): I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation. +1 for introducing a new convenient method {{Instance.isResolved()}} (or any other better name). > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Sep 8 06:01:25 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 08 Sep 2015 10:01:25 +0000 Subject: [cdi-dev] Canceling today's meeting Message-ID: Hi all, Let's skip to next week. I'll work on F2F agenda until then. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150908/c0369de8/attachment.html From issues at jboss.org Tue Sep 8 08:22:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Tue, 8 Sep 2015 08:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106296#comment-13106296 ] Sven Linstaedt commented on CDI-519: ------------------------------------ {quote} In your example if we go for 1, there will be no solution to destroy the instance you requested thru CDI. {quote} I would expect {{CDI}} as an {{Instance}} implementation to be dependent scoped and therefore live as long as {{CDI.current()}} returns the same instance. The later point is afaik not defined, but from my point of view, this {{Instance}}'s lifecycle is bound to the {{BeanManager}}'s one, as CDI.current() is available as long as the associated BeanManager is, which is the case at least for Weld as Martin stated. > Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object > ------------------------------------------------------------------------------------------------------ > > Key: CDI-519 > URL: https://issues.jboss.org/browse/CDI-519 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > 5.6.1. The Instance interface: > {quote} > The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or... > {quote} > I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec: > {code:java} > @Dependent > class Bar { > } > class Foo { > @Inject > Instance instance; > void ping() { > instance.destroy(CDI.current().select(Bar.class).get()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 08:55:00 2015 From: issues at jboss.org (Jirka Kremser (JIRA)) Date: Tue, 8 Sep 2015 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-51) Support static injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106310#comment-13106310 ] Jirka Kremser commented on CDI-51: ---------------------------------- Competitor has it https://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/spi/StaticInjectionRequest.html > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 08:59:00 2015 From: issues at jboss.org (Jirka Kremser (JIRA)) Date: Tue, 8 Sep 2015 08:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-51) Support static injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106310#comment-13106310 ] Jirka Kremser edited comment on CDI-51 at 9/8/15 8:58 AM: ---------------------------------------------------------- Competitor has it https://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/spi/StaticInjectionRequest.html I can imagine following use case: Some kind of utility class with all the method static that would like to use some injected field. was (Author: jkremser): Competitor has it https://google.github.io/guice/api-docs/latest/javadoc/index.html?com/google/inject/spi/StaticInjectionRequest.html > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 09:25:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Sep 2015 09:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-51) Support static injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106329#comment-13106329 ] Martin Kouba commented on CDI-51: --------------------------------- Note that the enum support was dropped, mainly because: {quote} There is a problem with the injection part if the enum is shared across multiple CDI applications. {quote} See also CDI-293. I think there might be similar problems with static injection. > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From jharting at redhat.com Tue Sep 8 15:03:53 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 8 Sep 2015 15:03:53 -0400 Subject: [cdi-dev] Changes to the Weld team Message-ID: <55EF3119.70809@redhat.com> http://weld.cdi-spec.org/news/2015/09/08/weld-team-changes/ From ggastald at redhat.com Tue Sep 8 15:24:12 2015 From: ggastald at redhat.com (George Gastaldi) Date: Tue, 8 Sep 2015 16:24:12 -0300 Subject: [cdi-dev] Changes to the Weld team In-Reply-To: <55EF3119.70809@redhat.com> References: <55EF3119.70809@redhat.com> Message-ID: Awesome! Congrats Martin! Welcome Mat?j! On Tue, Sep 8, 2015 at 4:03 PM, Jozef Hartinger wrote: > http://weld.cdi-spec.org/news/2015/09/08/weld-team-changes/ > _______________________________________________ > 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. > -- *George Gastaldi | Senior Software Engineer* JBoss Forge Team T: +55 11 3524-6169 M: +55 47 9711-1000 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150908/8b9b9a88/attachment.html From antoine at sabot-durand.net Tue Sep 8 15:56:06 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 08 Sep 2015 19:56:06 +0000 Subject: [cdi-dev] Changes to the Weld team In-Reply-To: References: <55EF3119.70809@redhat.com> Message-ID: Good luck Jozef ! Le mar. 8 sept. 2015 ? 21:24, George Gastaldi a ?crit : > Awesome! Congrats Martin! Welcome Mat?j! > > On Tue, Sep 8, 2015 at 4:03 PM, Jozef Hartinger > wrote: > >> http://weld.cdi-spec.org/news/2015/09/08/weld-team-changes/ >> _______________________________________________ >> 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. >> > > > > -- > *George Gastaldi | Senior Software Engineer* > > JBoss Forge Team > T: +55 11 3524-6169 > M: +55 47 9711-1000 > _______________________________________________ > 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/20150908/383d5639/attachment.html From struberg at yahoo.de Wed Sep 9 02:50:25 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 9 Sep 2015 08:50:25 +0200 Subject: [cdi-dev] [weld-dev] Changes to the Weld team In-Reply-To: <55EF3119.70809@redhat.com> References: <55EF3119.70809@redhat.com> Message-ID: <4B21C5D4-377B-4CBF-B96E-E8E6D02CDF5A@yahoo.de> Hi Jozef! Txs for all the great discussions and good luck to your new endeavours! And congrats, Martin and welcome Matej! LieGrue, strub > Am 08.09.2015 um 21:03 schrieb Jozef Hartinger : > > http://weld.cdi-spec.org/news/2015/09/08/weld-team-changes/ > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev From emijiang6 at googlemail.com Wed Sep 9 05:39:23 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 9 Sep 2015 10:39:23 +0100 Subject: [cdi-dev] [weld-dev] Changes to the Weld team In-Reply-To: <4B21C5D4-377B-4CBF-B96E-E8E6D02CDF5A@yahoo.de> References: <55EF3119.70809@redhat.com> <4B21C5D4-377B-4CBF-B96E-E8E6D02CDF5A@yahoo.de> Message-ID: Thank you Jozef for all of your help and good luck with your new job! Congratulations Martin! Welcome Mat?j! On Wed, Sep 9, 2015 at 7:50 AM, Mark Struberg wrote: > Hi Jozef! > > Txs for all the great discussions and good luck to your new endeavours! > And congrats, Martin and welcome Matej! > > LieGrue, > strub > > > Am 08.09.2015 um 21:03 schrieb Jozef Hartinger : > > > > http://weld.cdi-spec.org/news/2015/09/08/weld-team-changes/ > > _______________________________________________ > > weld-dev mailing list > > weld-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > 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. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150909/e9994761/attachment.html From issues at jboss.org Thu Sep 10 06:32:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Thu, 10 Sep 2015 06:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-559) typo on page 113 In-Reply-To: References: Message-ID: Emily Jiang created CDI-559: ------------------------------- Summary: typo on page 113 Key: CDI-559 URL: https://issues.jboss.org/browse/CDI-559 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 2.0-EDR1 Environment: n/a Reporter: Emily Jiang Priority: Trivial On CDI 2.0 spec page 113 @javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 06:36:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Thu, 10 Sep 2015 06:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) bean archive In-Reply-To: References: Message-ID: Emily Jiang created CDI-560: ------------------------------- Summary: bean archive Key: CDI-560 URL: https://issues.jboss.org/browse/CDI-560 Project: CDI Specification Issues Issue Type: Clarification Components: Concepts Affects Versions: 2.0-EDR1 Environment: Section 5.1 Modularity: The library is a bean archive if it contains a beans.xml file, as defined in Bean archives. It contradicts with the section 12.1 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. Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". I think it is better to be "The library may be a bean archive, as defined in Bean archives." Reporter: Emily Jiang Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 06:52:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 10 Sep 2015 06:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-560: ----------------------------- Summary: A bean archive does not have to contain a beans.xml file (was: bean archive) > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > 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. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 06:53:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 10 Sep 2015 06:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-560: ----------------------------- Description: Section 5.1 Modularity: The library is a bean archive if it contains a beans.xml file, as defined in Bean archives. It contradicts with the section 12.1 {quote} 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. {quote} Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". I think it is better to be "The library may be a bean archive, as defined in Bean archives." > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > 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. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > 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. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 06:55:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 10 Sep 2015 06:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107354#comment-13107354 ] Martin Kouba commented on CDI-560: ---------------------------------- Moreover, an implicit bean archive does not have to contain beans.xml at all: {quote} An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. {quote} > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > 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. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > 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. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 09:50:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Thu, 10 Sep 2015 09:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107432#comment-13107432 ] Emily Jiang commented on CDI-560: --------------------------------- That is true Martin! Hence my suggestion:o > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > 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. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > 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. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 09:53:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 10 Sep 2015 09:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-560: ------------------------------------- Fix Version/s: 2.0 (proposed) > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > 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. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > 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. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Sun Sep 13 18:32:49 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 13 Sep 2015 22:32:49 +0000 Subject: [cdi-dev] Not at the next two meetings Message-ID: Hey guys, I won't be able to make it to the next 2 meetings, will be on PTO for about a week and a half. Have fun at the f2f! John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150913/cae0faba/attachment.html From antoine at sabot-durand.net Mon Sep 14 07:55:02 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 14 Sep 2015 11:55:02 +0000 Subject: [cdi-dev] tomorrow's meeting agenda Message-ID: Hi all, Tomorrow I propose that we discuss the session and organization of the F2F meeting. It's still time to give the subject you'd like to discuss during this meeting or vote for an existing topic: https://docs.google.com/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150914/4e07f1ff/attachment.html From issues at jboss.org Tue Sep 15 06:59:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 15 Sep 2015 06:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-544) 10.2.3. The Event interface - provided executor cannot execute observers notification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-544: ---------------------------- Affects Version/s: 2.0-EDR1 > 10.2.3. The Event interface - provided executor cannot execute observers notification > ------------------------------------------------------------------------------------- > > Key: CDI-544 > URL: https://issues.jboss.org/browse/CDI-544 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > > {quote} > If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown. > {quote} > What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE? > This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}. > Maybe this sentence could be omitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 11:34:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 11:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-561: ---------------------------------------- Summary: Add the possibility to unmanage an instance Key: CDI-561 URL: https://issues.jboss.org/browse/CDI-561 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0-EDR1, 1.2.Final, 1.1.Final Reporter: Antoine Sabot-Durand -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 11:47:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 11:47:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Fix Version/s: 2.0 (discussion) > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 11:47:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 11:47:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Description: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 11:49:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 11:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Description: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. was: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 11:51:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 11:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Summary: Add the possibility to unmanage a bean instance (was: Add the possibility to unmanage an instance) > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 12:06:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 15 Sep 2015 12:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-562) Add the possibility to retrieve {{Bean}} from one of its instance In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-562: ---------------------------------------- Summary: Add the possibility to retrieve {{Bean}} from one of its instance Key: CDI-562 URL: https://issues.jboss.org/browse/CDI-562 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Antoine Sabot-Durand Since CDI 1.1 it's possible to inject its meta data in a bean instance wit {{@Inject Bean meta;}}. Its very useful to get information like actual class or qualifier on the current bean. This feature is great when we own the code and can add the injection point but when the bean is defined in a third party lib this information are not reachable. It would be nice to have a method in the {{BeanManager}} or elsewhere being able to return the Bean corresponding to a T instance or {{null}} if the instance is not managed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 04:48:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 04:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-562) Add the possibility to retrieve {{Bean}} from one of its instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109799#comment-13109799 ] Martin Kouba commented on CDI-562: ---------------------------------- I think there are two similar open issues which might offer a better solution for this use case: # CDI-515 - allow to obtain Bean metadata from {{javax.enterprise.inject.Instance}}, so that if a user wants to get the metadata the programmatic lookup would help # CDI-10 - if we introduce a marking interface for client proxies, e.g. {{BeanProxy}}, we could also probably add {{getBean()}} method I'm not so sure it's a good idea to add a method to the BeanManager. Let's have the following producer: {code:java} clas FooProducer { @Alpha // qualifier @Produces Foo produceAlphaFoo() { ... } @Bravo // qualifier @Produces Foo produceBravoFoo() { ... } } {code} How to identify a bean for any {{Foo}} instance? We would have to use some internal construct even for contextual instances of dependent beans with no interceptors/decorators. And that's not possible - such a bean does not have to be proxyable. Or am I missing something? > Add the possibility to retrieve {{Bean}} from one of its instance > -------------------------------------------------------------------- > > Key: CDI-562 > URL: https://issues.jboss.org/browse/CDI-562 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > > Since CDI 1.1 it's possible to inject its meta data in a bean instance wit {{@Inject Bean meta;}}. Its very useful to get information like actual class or qualifier on the current bean. > This feature is great when we own the code and can add the injection point but when the bean is defined in a third party lib this information are not reachable. > It would be nice to have a method in the {{BeanManager}} or elsewhere being able to return the Bean corresponding to a T instance or {{null}} if the instance is not managed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 04:53:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 04:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109806#comment-13109806 ] Martin Kouba commented on CDI-561: ---------------------------------- bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I think this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 04:54:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 04:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109806#comment-13109806 ] Martin Kouba edited comment on CDI-561 at 9/17/15 4:53 AM: ----------------------------------------------------------- bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I believe this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. was (Author: mkouba): bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I think this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 05:10:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 05:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-532) Support multiple container in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109819#comment-13109819 ] Martin Kouba commented on CDI-532: ---------------------------------- Note that Weld SE 2.3 already supports multiple *isolated* containers. The containers may share the bean classes. However, a user is required to assign a unique ID per container started. See also http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/#_enhanced_api_for_weld_se. I did not study jigsaw but if the requirement is to be able to run multiple isolated containers in one JVM, it does not really matter (it should work similarly in any modular environment). > Support multiple container in Java SE > ------------------------------------- > > Key: CDI-532 > URL: https://issues.jboss.org/browse/CDI-532 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > We should propose a solution to support multiple container in Java SE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 08:01:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 08:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109929#comment-13109929 ] Martin Kouba commented on CDI-383: ---------------------------------- Well, an HTTP session does not have to be destroyed after a container is shut down. This is not defined in the servlet spec and I did not find anything relevant in the Java EE spec. See also CDITCK-482 comments. However, if we redefine this and state that it's destroyed after an HTTP session is invalidated, we would probably break backward compatibility (see also CDI-497). > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 09:26:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 09:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109994#comment-13109994 ] Martin Kouba commented on CDI-547: ---------------------------------- So we have three options: * add overloaded {{resolveObserverMethods()}} with an extra {{boolean}} param to distinguish between {{fire()}} and {{fireAsync()}}, the original method follows {{fire()}} semantics * add a new method, e.g. something like {{resolveObserverMethodsForFireAsync()}} * do not add any methods, and let a consumer filter out sync/async observers as needed, i.e. sync + async observers for {{fireAsync()}} and sync for {{fire()}} The other question is ordering. IMO this depends on the result of CDI-541. I.e. if async observers would not honor ordering the set does not have to be "ordered" at all. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 09:46:01 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 17 Sep 2015 09:46:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110012#comment-13110012 ] Tomas Remes commented on CDI-547: --------------------------------- Yes maybe the third option looks as the best one to me. Because when you introduce new method then there is a question: What all should it return in case of ASYNC version? It would make sense to return all ASYNC + SYNC observers but I think this will bring only more confusion. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 09:53:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Sep 2015 09:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110017#comment-13110017 ] Martin Kouba commented on CDI-547: ---------------------------------- Yep, it would return both ASYNC + SYNC, the same result one would expect for {{fireAsync()}}. That's why the proposed name contains *ForFireAsync*. The third option may also bring confusion - we will always return observer methods for {{fireAsync()}}. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Sep 21 03:10:08 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 21 Sep 2015 07:10:08 +0000 Subject: [cdi-dev] No meeting tomorrow Message-ID: Hi Guys, I'll focus on the F2F meeting preparation. So no meeting tomorrow Regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150921/f0e51a71/attachment.html From issues at jboss.org Mon Sep 21 09:14:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 21 Sep 2015 09:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110833#comment-13110833 ] Martin Kouba commented on CDI-20: --------------------------------- I'm not so sure it's a good idea to allow any observer to abort processing of an event. This would be another way to kill the original concept of decoupled interactiion. Ordering might be sometimes handy but to allow to abort the processing seems to me a bit too much. For some use cases it might be better to implement a mutable thread-safe event payload with a flag (as mentioned above) and let the observers handle this alone (e.g. the first one marks the payload as handled and others just skip the processing). > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 10:50:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 21 Sep 2015 10:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: Martin Kouba created CDI-563: -------------------------------- Summary: Event.fireAsync() - clarify the usage of the returned CompletionStage Key: CDI-563 URL: https://issues.jboss.org/browse/CDI-563 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 2.0-EDR1 Reporter: Martin Kouba So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: {quote} * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. {quote} So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: {code:java} event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); {code} And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Wed Sep 23 04:20:50 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 23 Sep 2015 08:20:50 +0000 Subject: [cdi-dev] F2F participants Message-ID: Hi guys, So the meeting is starting friday in Paris. So far beyond the Red Hat guys I have only 2 or 3 participants: - Antonio - Emily - Werner (maybe) Did I forget someone ? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/acb3047c/attachment.html From antoine at sabot-durand.net Wed Sep 23 06:03:07 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 23 Sep 2015 10:03:07 +0000 Subject: [cdi-dev] Opening CDI F2F meeting to the community Message-ID: Hi all, As a lot of EG members won't make it for our meeting, if you follow this ml are in Paris on Friday and/or Saturday you can join us for our meeting. Send me a private email if you are interested. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/7533fdae/attachment.html From issues at jboss.org Sat Sep 26 08:55:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-515: ----------------------------- Fix Version/s: (was: 2.0 (discussion)) > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 08:55:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-515: ----------------------------- Fix Version/s: 2.0 (proposed) > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 08:56:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 08:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112713#comment-13112713 ] Martin Kouba commented on CDI-515: ---------------------------------- Accepted on F2F. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 09:05:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 09:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112714#comment-13112714 ] Martin Kouba commented on CDI-526: ---------------------------------- We can make use of Weld non-portable feature: bq. If both include filters and excludes filters are specified, only class names which match at least one include filter and don't match any exclude filter are scanned. > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 09:05:01 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 09:05:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-526: ----------------------------- Fix Version/s: 2.0 (proposed) > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 09:37:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 26 Sep 2015 09:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-458: ----------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From werner.keil at gmail.com Sat Sep 26 10:20:42 2015 From: werner.keil at gmail.com (Werner Keil) Date: Sat, 26 Sep 2015 16:20:42 +0200 Subject: [cdi-dev] Opening CDI F2F meeting to the community Message-ID: Guys, Only getting this digest now, but wanted to reply in any case. Sorry, I could not make it this time. Primarily due to more travel coming up, as DevoXX BE in Antwerp also invited me and 2 JSR 363 EG members to talk. A significant number of EG members, especially those in Paris or France are likely to go there, if they're not already at JavaOne (I should be at the EC F2F and JavaOne, as long as PMO approves the travel request to go there and tickets are still available ;-) thus I will meet almost all of those in Paris now at either of these occasions or both. Enjoy the stay and see you soon, Werner On Sat, Sep 26, 2015 at 2:55 PM, 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. [JBoss JIRA] (CDI-383) Clarify that session context is also > destroyed at shutdown/undeploy (Martin Kouba (JIRA)) > 2. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods > (Martin Kouba (JIRA)) > 3. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods > (Tomas Remes (JIRA)) > 4. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods > (Martin Kouba (JIRA)) > 5. No meeting tomorrow (Antoine Sabot-Durand) > 6. [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop > event propagation after being handled by an observer > (Martin Kouba (JIRA)) > 7. [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage > of the returned CompletionStage (Martin Kouba (JIRA)) > 8. F2F participants (Antoine Sabot-Durand) > 9. Opening CDI F2F meeting to the community (Antoine Sabot-Durand) > 10. [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from > javax.enterprise.inject.Instance (Martin Kouba (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Sep 2015 08:01:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context > is also destroyed at shutdown/undeploy > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109929#comment-13109929 > ] > > Martin Kouba commented on CDI-383: > ---------------------------------- > > Well, an HTTP session does not have to be destroyed after a container is > shut down. This is not defined in the servlet spec and I did not find > anything relevant in the Java EE spec. See also CDITCK-482 comments. > However, if we redefine this and state that it's destroyed after an HTTP > session is invalidated, we would probably break backward compatibility (see > also CDI-497). > > > Clarify that session context is also destroyed at shutdown/undeploy > > ------------------------------------------------------------------- > > > > Key: CDI-383 > > URL: https://issues.jboss.org/browse/CDI-383 > > Project: CDI Specification Issues > > Issue Type: Bug > > Components: Contexts > > Affects Versions: 1.1.PFD > > Reporter: Marko Luk?a > > > > Section 6.7.2. states "The session context is destroyed > > when the HTTPSession times out, after all HttpSessionListener s have > been called, and at the very end of any request > > in which invalidate() was called, after all filters and > ServletRequestListener s have been called." > > The first part of the above sentence should not only say that the > context is destroyed after all listeners have been called specifically in > the event of a session timeout. It should specify that this is also true > when the session is being destroyed as a result of server shutdown or > web-app undeploy. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Sep 2015 09:26:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async > observer methods > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109994#comment-13109994 > ] > > Martin Kouba commented on CDI-547: > ---------------------------------- > > So we have three options: > * add overloaded {{resolveObserverMethods()}} with an extra {{boolean}} > param to distinguish between {{fire()}} and {{fireAsync()}}, the original > method follows {{fire()}} semantics > * add a new method, e.g. something like > {{resolveObserverMethodsForFireAsync()}} > * do not add any methods, and let a consumer filter out sync/async > observers as needed, i.e. sync + async observers for {{fireAsync()}} and > sync for {{fire()}} > > The other question is ordering. IMO this depends on the result of CDI-541. > I.e. if async observers would not honor ordering the set does not have to > be "ordered" at all. > > > Resolving sync/async observer methods > > ------------------------------------- > > > > Key: CDI-547 > > URL: https://issues.jboss.org/browse/CDI-547 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Reporter: Jozef Hartinger > > > > There's the [BeanManager.resolveObserverMethods()| > http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] > method for resolving observer methods. > > With addition of sync/async events and observers it is not unclear what > the semantics of this methods are. We'll most likely need to add new or > overloaded methods to make it possible to resolve observers for sync/async > events. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Sep 2015 09:46:01 -0400 (EDT) > From: "Tomas Remes (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async > observer methods > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110012#comment-13110012 > ] > > Tomas Remes commented on CDI-547: > --------------------------------- > > Yes maybe the third option looks as the best one to me. Because when you > introduce new method then there is a question: What all should it return in > case of ASYNC version? It would make sense to return all ASYNC + SYNC > observers but I think this will bring only more confusion. > > > Resolving sync/async observer methods > > ------------------------------------- > > > > Key: CDI-547 > > URL: https://issues.jboss.org/browse/CDI-547 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Reporter: Jozef Hartinger > > > > There's the [BeanManager.resolveObserverMethods()| > http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] > method for resolving observer methods. > > With addition of sync/async events and observers it is not unclear what > the semantics of this methods are. We'll most likely need to add new or > overloaded methods to make it possible to resolve observers for sync/async > events. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 4 > Date: Thu, 17 Sep 2015 09:53:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async > observer methods > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110017#comment-13110017 > ] > > Martin Kouba commented on CDI-547: > ---------------------------------- > > Yep, it would return both ASYNC + SYNC, the same result one would expect > for {{fireAsync()}}. That's why the proposed name contains *ForFireAsync*. > > The third option may also bring confusion - we will always return observer > methods for {{fireAsync()}}. > > > Resolving sync/async observer methods > > ------------------------------------- > > > > Key: CDI-547 > > URL: https://issues.jboss.org/browse/CDI-547 > > Project: CDI Specification Issues > > Issue Type: Clarification > > Reporter: Jozef Hartinger > > > > There's the [BeanManager.resolveObserverMethods()| > http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] > method for resolving observer methods. > > With addition of sync/async events and observers it is not unclear what > the semantics of this methods are. We'll most likely need to add new or > overloaded methods to make it possible to resolve observers for sync/async > events. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 5 > Date: Mon, 21 Sep 2015 07:10:08 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] No meeting tomorrow > To: cdi-dev > Message-ID: > 0Lw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Guys, > > I'll focus on the F2F meeting preparation. So no meeting tomorrow > > Regards, > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150921/f0e51a71/attachment-0001.html > > ------------------------------ > > Message: 6 > Date: Mon, 21 Sep 2015 09:14:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) > - stop event propagation after being handled by an observer > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110833#comment-13110833 > ] > > Martin Kouba commented on CDI-20: > --------------------------------- > > I'm not so sure it's a good idea to allow any observer to abort processing > of an event. This would be another way to kill the original concept of > decoupled interactiion. Ordering might be sometimes handy but to allow to > abort the processing seems to me a bit too much. For some use cases it > might be better to implement a mutable thread-safe event payload with a > flag (as mentioned above) and let the observers handle this alone (e.g. the > first one marks the payload as handled and others just skip the processing). > > > @Observes(propagate = false) - stop event propagation after being > handled by an observer > > > ---------------------------------------------------------------------------------------- > > > > Key: CDI-20 > > URL: https://issues.jboss.org/browse/CDI-20 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Events > > Affects Versions: 1.0 > > Environment: any > > Reporter: Walter White > > Fix For: 2.0 (discussion) > > > > > > I would like to have the ability to stop event propagation after it is > handled by any observer only for certain situations. Is it possible to add > a property to the annotation indicating whether the propagation should > continue after being handled by the observer? Alternatively, would it be > more concise to add a qualifier annotation which specifies the propagation. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 7 > Date: Mon, 21 Sep 2015 10:50:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify > the usage of the returned CompletionStage > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Martin Kouba created CDI-563: > -------------------------------- > > Summary: Event.fireAsync() - clarify the usage of the > returned CompletionStage > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple > exceptions thrown during an asynchronous event" and the > {{Event.fireAsync()}} javadoc is too general. However, the > {{CompletionStage}} itself does not define an unambiguous contract for its > methods. E.g. what thread is used to execute a given callback? Or what's > the _"stage's default asynchronous execution facility"_? I believe this is > left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} > under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be > performed by the thread that completes the current CompletableFuture, or by > any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent > action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This > might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point > of view. I think the spec should clarify the contract of a returned > {{CompletionStage}}. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > Message: 8 > Date: Wed, 23 Sep 2015 08:20:50 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] F2F participants > To: cdi-dev > Message-ID: > a8N6NdmMRJxUMncuGTpDdV2WyUesoLTMqPDQdw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi guys, > > So the meeting is starting friday in Paris. So far beyond the Red Hat guys > I have only 2 or 3 participants: > > - Antonio > - Emily > - Werner (maybe) > > Did I forget someone ? > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/acb3047c/attachment-0001.html > > ------------------------------ > > Message: 9 > Date: Wed, 23 Sep 2015 10:03:07 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Opening CDI F2F meeting to the community > To: cdi-dev > Message-ID: > 6L0eK+i7SWKdEu-9Uu-BUeTU5dGzgjg+w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > As a lot of EG members won't make it for our meeting, if you follow this ml > are in Paris on Friday and/or Saturday you can join us for our meeting. > Send me a private email if you are interested. > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/7533fdae/attachment-0001.html > > ------------------------------ > > Message: 10 > Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean > metadata from javax.enterprise.inject.Instance > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Martin Kouba updated CDI-515: > ----------------------------- > Fix Version/s: (was: 2.0 (discussion)) > > > > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > > ------------------------------------------------------------------- > > > > Key: CDI-515 > > URL: https://issues.jboss.org/browse/CDI-515 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Affects Versions: 1.2.Final > > Reporter: Martin Kouba > > Fix For: 2.0 (proposed) > > > > > > Sometimes it might be useful to obtain Bean metadata from the > {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). > The method could be named {{getBean()}} and should have similar > restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} > if appropriate). > > > > -- > This message was sent by Atlassian JIRA > (v6.4.11#64026) > > > ------------------------------ > > _______________________________________________ > 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 15 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150926/9c4a85ac/attachment-0001.html From issues at jboss.org Sat Sep 26 10:55:00 2015 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 26 Sep 2015 10:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112720#comment-13112720 ] Antonio Goncalves commented on CDI-497: --------------------------------------- In Servlet 3.1 ?7.5 it's written : {quote} The session invalidation will not take effect until all servlets using that session have exited the service method {quote} > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 (discussion) > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Sep 26 10:57:00 2015 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Sat, 26 Sep 2015 10:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112721#comment-13112721 ] Antonio Goncalves commented on CDI-383: --------------------------------------- In Servlet 3.1 spec ?11.3.4 Notifications At Shutdown {quote} On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown. {quote} > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From emijiang6 at googlemail.com Mon Sep 28 08:45:27 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 28 Sep 2015 13:45:27 +0100 Subject: [cdi-dev] F2F participants In-Reply-To: References: Message-ID: Thank you Antoine for your great hospitality! We had very productive two days. It was great to meet all of you! On Wed, Sep 23, 2015 at 9:20 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > So the meeting is starting friday in Paris. So far beyond the Red Hat guys > I have only 2 or 3 participants: > > - Antonio > - Emily > - Werner (maybe) > > Did I forget someone ? > > Antoine > > > _______________________________________________ > 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. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150928/1f9692e8/attachment.html From antoine at sabot-durand.net Mon Sep 28 10:29:37 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 28 Sep 2015 14:29:37 +0000 Subject: [cdi-dev] Feedback of CDI F2F Message-ID: Hi all, We had a great time in Paris last week in our Face to Face meeting. First I'd like to thank all the participant who brought their ideas, experience and knowledge to this nice meeting: - Martin Kouba (Mr Weld) - Tomas Remes (Mr TCK) - Antonio Goncalves (Mr Java EE) - Emily Jiang (Ms Liberty Profile) - Yann Blazart (Mr End user on OpenWebBeans) And as a guest star: Emmanuel Bernard (Mr Third Party Spec) I initially wanted to share the feedback here, but it's too long, so I'm preparing a blog post on the website. It'll be published tonight or tomorrow morning. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150928/44f27809/attachment.html From antoine at sabot-durand.net Tue Sep 29 05:36:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 29 Sep 2015 09:36:13 +0000 Subject: [cdi-dev] Blog post on F2F feedback Message-ID: Hi guys, The blog post is here : http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ I probably forgot a few stuff (I still have to check in everybody's note) but the main topics are here. As always, feed is welcome and we'll discuss these point sin today's meeting. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150929/39553380/attachment.html From struberg at yahoo.de Wed Sep 30 02:29:54 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 30 Sep 2015 08:29:54 +0200 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: References: Message-ID: Hi Antoine! Side question: what is the state of our GIT repo? Where can we find the latest and greatest and a set of things (branches) people are working on. Master still seems to not reflect the latest changes. Anyone has an oversight and can fix this please? txs and LieGrue, strub > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand : > > Hi guys, > > The blog post is here : > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > I probably forgot a few stuff (I still have to check in everybody's note) but the main topics are here. > > As always, feed is welcome and we'll discuss these point sin today's meeting. > > Antoine > _______________________________________________ > 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. From antoine at sabot-durand.net Wed Sep 30 02:38:38 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 30 Sep 2015 06:38:38 +0000 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: References: Message-ID: Still have the 2.0-EDR1 branch. I still don't see the urgence to merge it to master, since we are thinking about reviewing SE boot. But I put 2.0-EDR1 as default branch on Github. Honestly I don't think people unable to find last commit in a github repo are the best choice for contributors to the spec ;). Antoine Le mer. 30 sept. 2015 ? 08:29, Mark Struberg a ?crit : > Hi Antoine! > > Side question: what is the state of our GIT repo? > Where can we find the latest and greatest and a set of things (branches) > people are working on. > Master still seems to not reflect the latest changes. Anyone has an > oversight and can fix this please? > > txs and LieGrue, > strub > > > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > Hi guys, > > > > The blog post is here : > > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > > > I probably forgot a few stuff (I still have to check in everybody's > note) but the main topics are here. > > > > As always, feed is welcome and we'll discuss these point sin today's > meeting. > > > > Antoine > > _______________________________________________ > > 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/20150930/65fb59d4/attachment.html From struberg at yahoo.de Wed Sep 30 03:34:52 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 30 Sep 2015 09:34:52 +0200 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: References: Message-ID: <510D3817-6B18-453A-AB5F-8776E0A8FEE7@yahoo.de> This has nothing to do with the technical ability to find the last commit. It has purely to do that EDR-1 is FINISHED! This was a nice pun that we do it the wrong way if we continue on this branch? I suggest we update the docs in master and pull over the parts we like from EDR-1 and put the rest on the TODO list. You can also create a new branch for EDR-2 or CDI20-M2 or whatever you like to call it. LieGrue, strub > Am 30.09.2015 um 08:38 schrieb Antoine Sabot-Durand : > > Still have the 2.0-EDR1 branch. > > I still don't see the urgence to merge it to master, since we are thinking about reviewing SE boot. But I put 2.0-EDR1 as default branch on Github. > Honestly I don't think people unable to find last commit in a github repo are the best choice for contributors to the spec ;). > > Antoine > > > Le mer. 30 sept. 2015 ? 08:29, Mark Struberg a ?crit : > Hi Antoine! > > Side question: what is the state of our GIT repo? > Where can we find the latest and greatest and a set of things (branches) people are working on. > Master still seems to not reflect the latest changes. Anyone has an oversight and can fix this please? > > txs and LieGrue, > strub > > > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand : > > > > Hi guys, > > > > The blog post is here : > > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > > > I probably forgot a few stuff (I still have to check in everybody's note) but the main topics are here. > > > > As always, feed is welcome and we'll discuss these point sin today's meeting. > > > > Antoine > > _______________________________________________ > > 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. > From antoine at sabot-durand.net Wed Sep 30 03:56:03 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 30 Sep 2015 07:56:03 +0000 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: <510D3817-6B18-453A-AB5F-8776E0A8FEE7@yahoo.de> References: <510D3817-6B18-453A-AB5F-8776E0A8FEE7@yahoo.de> Message-ID: No it has to do with JCP process : https://www.jcp.org/ja/procedures/jcp2#3.1 and no EDR 1 is not "FINISHED!". Draft is finished but review part will be in 5 days (oct 5) : https://jcp.org/en/jsr/detail?id=365 There will be a ballot on it starting oct 5. This said, you're right, we won't continue on this branch. I said that there's no urgence since we don't have things to commit right away (to my knowledge). It'll change in the coming days. Antoine Le mer. 30 sept. 2015 ? 09:34, Mark Struberg a ?crit : > This has nothing to do with the technical ability to find the last commit. > It has purely to do that EDR-1 is FINISHED! This was a nice pun that we do > it the wrong way if we continue on this branch? > > I suggest we update the docs in master and pull over the parts we like > from EDR-1 and put the rest on the TODO list. > You can also create a new branch for EDR-2 or CDI20-M2 or whatever you > like to call it. > > LieGrue, > strub > > > Am 30.09.2015 um 08:38 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > Still have the 2.0-EDR1 branch. > > > > I still don't see the urgence to merge it to master, since we are > thinking about reviewing SE boot. But I put 2.0-EDR1 as default branch on > Github. > > Honestly I don't think people unable to find last commit in a github > repo are the best choice for contributors to the spec ;). > > > > Antoine > > > > > > Le mer. 30 sept. 2015 ? 08:29, Mark Struberg a > ?crit : > > Hi Antoine! > > > > Side question: what is the state of our GIT repo? > > Where can we find the latest and greatest and a set of things (branches) > people are working on. > > Master still seems to not reflect the latest changes. Anyone has an > oversight and can fix this please? > > > > txs and LieGrue, > > strub > > > > > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > > > Hi guys, > > > > > > The blog post is here : > > > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > > > > > I probably forgot a few stuff (I still have to check in everybody's > note) but the main topics are here. > > > > > > As always, feed is welcome and we'll discuss these point sin today's > meeting. > > > > > > Antoine > > > _______________________________________________ > > > 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/20150930/8cb28165/attachment.html From struberg at yahoo.de Wed Sep 30 04:00:34 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 30 Sep 2015 10:00:34 +0200 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: References: <510D3817-6B18-453A-AB5F-8776E0A8FEE7@yahoo.de> Message-ID: Oki, thanks for clarifying! The goal should be to make it as easy as possible for interested persons to contribute. And this requires to really push them to the current state (s)he can pull new changes from and apply their contributions on. Merging with Git is easier than with other scm systems, but it is not for free neither. It?s still much better to avoid merge conflicts than to have to merge sentences by hand. txs and LieGrue, strub > Am 30.09.2015 um 09:56 schrieb Antoine Sabot-Durand : > > No it has to do with JCP process : https://www.jcp.org/ja/procedures/jcp2#3.1 > and no EDR 1 is not "FINISHED!". Draft is finished but review part will be in 5 days (oct 5) : https://jcp.org/en/jsr/detail?id=365 > There will be a ballot on it starting oct 5. > > This said, you're right, we won't continue on this branch. I said that there's no urgence since we don't have things to commit right away (to my knowledge). It'll change in the coming days. > > Antoine > > > Le mer. 30 sept. 2015 ? 09:34, Mark Struberg a ?crit : > This has nothing to do with the technical ability to find the last commit. > It has purely to do that EDR-1 is FINISHED! This was a nice pun that we do it the wrong way if we continue on this branch? > > I suggest we update the docs in master and pull over the parts we like from EDR-1 and put the rest on the TODO list. > You can also create a new branch for EDR-2 or CDI20-M2 or whatever you like to call it. > > LieGrue, > strub > > > Am 30.09.2015 um 08:38 schrieb Antoine Sabot-Durand : > > > > Still have the 2.0-EDR1 branch. > > > > I still don't see the urgence to merge it to master, since we are thinking about reviewing SE boot. But I put 2.0-EDR1 as default branch on Github. > > Honestly I don't think people unable to find last commit in a github repo are the best choice for contributors to the spec ;). > > > > Antoine > > > > > > Le mer. 30 sept. 2015 ? 08:29, Mark Struberg a ?crit : > > Hi Antoine! > > > > Side question: what is the state of our GIT repo? > > Where can we find the latest and greatest and a set of things (branches) people are working on. > > Master still seems to not reflect the latest changes. Anyone has an oversight and can fix this please? > > > > txs and LieGrue, > > strub > > > > > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand : > > > > > > Hi guys, > > > > > > The blog post is here : > > > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > > > > > I probably forgot a few stuff (I still have to check in everybody's note) but the main topics are here. > > > > > > As always, feed is welcome and we'll discuss these point sin today's meeting. > > > > > > Antoine > > > _______________________________________________ > > > 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. > > > From antoine at sabot-durand.net Wed Sep 30 04:06:16 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 30 Sep 2015 08:06:16 +0000 Subject: [cdi-dev] Blog post on F2F feedback In-Reply-To: References: <510D3817-6B18-453A-AB5F-8776E0A8FEE7@yahoo.de> Message-ID: You're right. Right now master is only behind EDR1 (no fork). If it's bothering people here (like you ;) ) I can still put a tag on current master to keep track of "before EDR1" and merge the whole stuff. Antoine Le mer. 30 sept. 2015 ? 10:00, Mark Struberg a ?crit : > Oki, thanks for clarifying! > The goal should be to make it as easy as possible for interested persons > to contribute. And this requires to really push them to the current state > (s)he can pull new changes from and apply their contributions on. > > Merging with Git is easier than with other scm systems, but it is not for > free neither. It?s still much better to avoid merge conflicts than to have > to merge sentences by hand. > > txs and LieGrue, > strub > > > > > Am 30.09.2015 um 09:56 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > No it has to do with JCP process : > https://www.jcp.org/ja/procedures/jcp2#3.1 > > and no EDR 1 is not "FINISHED!". Draft is finished but review part will > be in 5 days (oct 5) : https://jcp.org/en/jsr/detail?id=365 > > There will be a ballot on it starting oct 5. > > > > This said, you're right, we won't continue on this branch. I said that > there's no urgence since we don't have things to commit right away (to my > knowledge). It'll change in the coming days. > > > > Antoine > > > > > > Le mer. 30 sept. 2015 ? 09:34, Mark Struberg a > ?crit : > > This has nothing to do with the technical ability to find the last > commit. > > It has purely to do that EDR-1 is FINISHED! This was a nice pun that we > do it the wrong way if we continue on this branch? > > > > I suggest we update the docs in master and pull over the parts we like > from EDR-1 and put the rest on the TODO list. > > You can also create a new branch for EDR-2 or CDI20-M2 or whatever you > like to call it. > > > > LieGrue, > > strub > > > > > Am 30.09.2015 um 08:38 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > > > Still have the 2.0-EDR1 branch. > > > > > > I still don't see the urgence to merge it to master, since we are > thinking about reviewing SE boot. But I put 2.0-EDR1 as default branch on > Github. > > > Honestly I don't think people unable to find last commit in a github > repo are the best choice for contributors to the spec ;). > > > > > > Antoine > > > > > > > > > Le mer. 30 sept. 2015 ? 08:29, Mark Struberg a > ?crit : > > > Hi Antoine! > > > > > > Side question: what is the state of our GIT repo? > > > Where can we find the latest and greatest and a set of things > (branches) people are working on. > > > Master still seems to not reflect the latest changes. Anyone has an > oversight and can fix this please? > > > > > > txs and LieGrue, > > > strub > > > > > > > Am 29.09.2015 um 11:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > > > > > Hi guys, > > > > > > > > The blog post is here : > > > > http://www.cdi-spec.org/news/2015/09/29/Second-F2F-meeting/ > > > > > > > > I probably forgot a few stuff (I still have to check in everybody's > note) but the main topics are here. > > > > > > > > As always, feed is welcome and we'll discuss these point sin today's > meeting. > > > > > > > > Antoine > > > > _______________________________________________ > > > > 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/20150930/6df2115f/attachment.html