From antonio.goncalves at gmail.com Sun Feb 1 07:36:20 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Sun, 1 Feb 2015 13:36:20 +0100 Subject: [cdi-dev] Clarify scopes and serialization Message-ID: Hi all, I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : *1.3.1. JSF example* *The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope types? is a scope* *type that specifies the lifecycle of instances of Login. Managed beans with this scope must be* *serializable.* The Weld documentation is a bit more explicit : *5.2. Built-in scopes* *Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time.* And in the Java EE Tutorial we find ( http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : *Beans that use session, application, or conversation scope must be serializable*, but beans that use request scope do not have to be serializable. This even made be doubt about the application scope ?!? Any way, could we clarify this in the CDI spec ? -- 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/20150201/eb2c612c/attachment.html From rmannibucau at gmail.com Sun Feb 1 10:44:17 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Feb 2015 16:44:17 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: Hi +1 to clarify it. All normal scope dont need Serializable constraint - even session scope - and it makes sense to not respect it in a lot of apps without preventing these beans to be serializable thans their proxies. Best IMO is to either remove it or to allow a scope serializer service to be specified to keep it portable. Wdyt? Le 1 f?vr. 2015 13:36, "Antonio Goncalves" a ?crit : > Hi all, > > I was reading the CDI 1.2 spec and couldn't clearly find the way > serialization and scopes work. The only explicit sentence I found was : > > > *1.3.1. JSF example* > > *The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope > types? is a scope* > *type that specifies the lifecycle of instances of Login. Managed beans > with this scope must be* > *serializable.* > > > The Weld documentation is a bit more explicit : > > *5.2. Built-in scopes* > *Managed beans with scope @SessionScoped or @ConversationScoped must be > serializable, since the container passivates the HTTP session from time to > time.* > > > And in the Java EE Tutorial we find ( > http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > *Beans that use session, application, or conversation scope must be > serializable*, but beans that use request scope do not have to be > serializable. > > > This even made be doubt about the application scope ?!? > > > Any way, could we clarify this in the CDI spec ? > > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150201/36d016cf/attachment.html From pmuir at redhat.com Sun Feb 1 11:07:55 2015 From: pmuir at redhat.com (Pete Muir) Date: Sun, 1 Feb 2015 16:07:55 +0000 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <1BB886DF-6B94-4531-894E-5063000EC05B@redhat.com> Look instead for passivation, you will find plenty. > On 1 Feb 2015, at 12:36, Antonio Goncalves wrote: > > Hi all, > > I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : > > > 1.3.1. JSF example > The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope types? is a scope > type that specifies the lifecycle of instances of Login. Managed beans with this scope must be > serializable. > > > The Weld documentation is a bit more explicit : > > 5.2. Built-in scopes > Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time. > > > And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html ) : > > Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. > > > This even made be doubt about the application scope ?!? > > > Any way, could we clarify this in the CDI spec ? > > > -- > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150201/57ad10d5/attachment-0001.html From rmannibucau at gmail.com Sun Feb 1 11:10:44 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Feb 2015 17:10:44 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <1BB886DF-6B94-4531-894E-5063000EC05B@redhat.com> References: <1BB886DF-6B94-4531-894E-5063000EC05B@redhat.com> Message-ID: Passivation is not bound to serialization - which is great - but I agree with Antonio Serialization part should be more explicit - even to say it is not needed when it is the case. Le 1 f?vr. 2015 17:08, "Pete Muir" a ?crit : > Look instead for passivation, you will find plenty. > > On 1 Feb 2015, at 12:36, Antonio Goncalves > wrote: > > Hi all, > > I was reading the CDI 1.2 spec and couldn't clearly find the way > serialization and scopes work. The only explicit sentence I found was : > > > *1.3.1. JSF example* > > *The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope > types? is a scope* > *type that specifies the lifecycle of instances of Login. Managed beans > with this scope must be* > *serializable.* > > > The Weld documentation is a bit more explicit : > > *5.2. Built-in scopes* > *Managed beans with scope @SessionScoped or @ConversationScoped must be > serializable, since the container passivates the HTTP session from time to > time.* > > > And in the Java EE Tutorial we find ( > http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > *Beans that use session, application, or conversation scope must be > serializable*, but beans that use request scope do not have to be > serializable. > > > This even made be doubt about the application scope ?!? > > > Any way, could we clarify this in the CDI spec ? > > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150201/48e729c6/attachment.html From struberg at yahoo.de Sun Feb 1 11:49:11 2015 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 1 Feb 2015 16:49:11 +0000 (UTC) Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <196394544.523175.1422809351378.JavaMail.yahoo@mail.yahoo.com> See 6.6.5 of the Spec. Serializable all over the place. The important point is also the difference between the requirement for Bean instances to be PassivationCapable and the Contextual Instances to be Serializable. E.g. for @ApplicationScoped the ContextualInstance doesn't need to be Serializable, but the Bean for it needs to be PassivationCapable. The reason is that the Bean instance gets stored in the Proxy. And this Proxy needs to be Serializable because otherwise you would not be able to inject it into a @SessionScoped bean (or any other bean with passivating scope). LieGrue, strub On Sunday, 1 February 2015, 13:37, Antonio Goncalves wrote: > > >Hi all, > > >I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : > > > > >1.3.1. JSF example >The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope types? is a scope > >type that specifies the lifecycle of instances of Login. Managed beans with this scope must be >serializable. > > > > >The Weld documentation is a bit more explicit : > > >5.2. Built-in scopes >Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time. > > > > >And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > >Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. > > > > > >This even made be doubt about the application scope ?!? > > > > >Any way, could we clarify this in the CDI spec ? > > > >-- > >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. > > From antoine at sabot-durand.net Mon Feb 2 09:43:57 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 2 Feb 2015 15:43:57 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 Message-ID: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> Hi all, https://issues.jboss.org/browse/CDI-499 comes after a lot of discussion about async events. I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn?t please a lot of us. It?ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(. I?d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150202/78c9f2af/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150202/78c9f2af/attachment.bin From antoine at sabot-durand.net Mon Feb 2 09:57:38 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 2 Feb 2015 15:57:38 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <196394544.523175.1422809351378.JavaMail.yahoo@mail.yahoo.com> References: <196394544.523175.1422809351378.JavaMail.yahoo@mail.yahoo.com> Message-ID: In 6.6.1 we have : ? A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of the bean are passivation capable. so the concept of ?passivation? is rather well defined. > Le 1 f?vr. 2015 ? 17:49, Mark Struberg a ?crit : > > See 6.6.5 of the Spec. Serializable all over the place. > > The important point is also the difference between the requirement for Bean instances to be PassivationCapable and the Contextual Instances to be Serializable. > > > E.g. for @ApplicationScoped the ContextualInstance doesn't need to be Serializable, but the Bean for it needs to be PassivationCapable. The reason is that the Bean instance gets stored in the Proxy. And this Proxy needs to be Serializable because otherwise you would not be able to inject it into a @SessionScoped bean (or any other bean with passivating scope). > > > > LieGrue, > strub > > > > > > On Sunday, 1 February 2015, 13:37, Antonio Goncalves wrote: > > >> >> >> Hi all, >> >> >> I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : >> >> >> >> >> 1.3.1. JSF example >> The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope types? is a scope >> >> type that specifies the lifecycle of instances of Login. Managed beans with this scope must be >> serializable. >> >> >> >> >> The Weld documentation is a bit more explicit : >> >> >> 5.2. Built-in scopes >> Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time. >> >> >> >> >> And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >> >> >> Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. >> >> >> >> >> >> This even made be doubt about the application scope ?!? >> >> >> >> >> Any way, could we clarify this in the CDI spec ? >> >> >> >> -- >> >> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150202/038aa914/attachment.bin From rmannibucau at gmail.com Mon Feb 2 10:00:38 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 2 Feb 2015 16:00:38 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: <196394544.523175.1422809351378.JavaMail.yahoo@mail.yahoo.com> Message-ID: ok, could it be relaxed for CDI 2.0 - at least for normal scoped beans? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-02 15:57 GMT+01:00 Antoine Sabot-Durand : > In 6.6.1 we have : > > ? A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of the bean are passivation capable. > so the concept of ?passivation? is rather well defined. > > > >> Le 1 f?vr. 2015 ? 17:49, Mark Struberg a ?crit : >> >> See 6.6.5 of the Spec. Serializable all over the place. >> >> The important point is also the difference between the requirement for Bean instances to be PassivationCapable and the Contextual Instances to be Serializable. >> >> >> E.g. for @ApplicationScoped the ContextualInstance doesn't need to be Serializable, but the Bean for it needs to be PassivationCapable. The reason is that the Bean instance gets stored in the Proxy. And this Proxy needs to be Serializable because otherwise you would not be able to inject it into a @SessionScoped bean (or any other bean with passivating scope). >> >> >> >> LieGrue, >> strub >> >> >> >> >> >> On Sunday, 1 February 2015, 13:37, Antonio Goncalves wrote: >> >> >>> >>> >>> Hi all, >>> >>> >>> I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : >>> >>> >>> >>> >>> 1.3.1. JSF example >>> The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope types? is a scope >>> >>> type that specifies the lifecycle of instances of Login. Managed beans with this scope must be >>> serializable. >>> >>> >>> >>> >>> The Weld documentation is a bit more explicit : >>> >>> >>> 5.2. Built-in scopes >>> Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time. >>> >>> >>> >>> >>> And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>> >>> >>> Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. >>> >>> >>> >>> >>> >>> This even made be doubt about the application scope ?!? >>> >>> >>> >>> >>> Any way, could we clarify this in the CDI spec ? >>> >>> >>> >>> -- >>> >>> 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. > > > _______________________________________________ > 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 jharting at redhat.com Mon Feb 2 10:10:14 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 02 Feb 2015 16:10:14 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <54CF9356.5060106@redhat.com> Can you elaborate? If a bean has a normal scope (passivating), it may need to be passivated. Are you talking about using a serialization tool that does not require objects to implement Serializable and using such tool to passivate a context? Jozef On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: > > Hi > > +1 to clarify it. All normal scope dont need Serializable constraint - > even session scope - and it makes sense to not respect it in a lot of > apps without preventing these beans to be serializable thans their > proxies. > > Best IMO is to either remove it or to allow a scope serializer service > to be specified to keep it portable. > > Wdyt? > > Le 1 f?vr. 2015 13:36, "Antonio Goncalves" > > a > ?crit : > > Hi all, > > I was reading the CDI 1.2 spec and couldn't clearly find the way > serialization and scopes work. The only explicit sentence I found > was : > > > /1.3.1. JSF example/ > /The @SessionScoped annotation defined in Section 2.4.1, ?Built-in > scope types? is a scope > / > /type that specifies the lifecycle of instances of Login. *Managed > beans with this scope must be*/ > /*serializable.*/ > > > The Weld documentation is a bit more explicit : > > /5.2. Built-in scopes/ > /*Managed beans with scope @SessionScoped or @ConversationScoped > must be serializable*, since the container passivates the HTTP > session from time to time./ > > > And in the Java EE Tutorial we find > (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > *Beans that use session, application, or conversation scope must > be serializable*, but beans that use request scope do not have to > be serializable. > > > This even made be doubt about the application scope ?!? > > > Any way, could we clarify this in the CDI spec ? > > > -- > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150202/b5963e59/attachment.html From antonio.goncalves at gmail.com Mon Feb 2 10:21:39 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 2 Feb 2015 16:21:39 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <54CF9356.5060106@redhat.com> References: <54CF9356.5060106@redhat.com> Message-ID: One thing is sure, when you have many JSF backing bean, you always end up implementing Seralizable all over the place or inject transient object. It would really simplify the code if Serialization was taken care by the container, without having to implement Seralizable. Antonio On Mon, Feb 2, 2015 at 4:10 PM, Jozef Hartinger wrote: > Can you elaborate? If a bean has a normal scope (passivating), it may > need to be passivated. Are you talking about using a serialization tool > that does not require objects to implement Serializable and using such tool > to passivate a context? > > Jozef > > > On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: > > Hi > > +1 to clarify it. All normal scope dont need Serializable constraint - > even session scope - and it makes sense to not respect it in a lot of apps > without preventing these beans to be serializable thans their proxies. > > Best IMO is to either remove it or to allow a scope serializer service to > be specified to keep it portable. > > Wdyt? > Le 1 f?vr. 2015 13:36, "Antonio Goncalves" > a ?crit : > >> Hi all, >> >> I was reading the CDI 1.2 spec and couldn't clearly find the way >> serialization and scopes work. The only explicit sentence I found was : >> >> >> *1.3.1. JSF example* >> >> *The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope >> types? is a scope * >> *type that specifies the lifecycle of instances of Login. Managed beans >> with this scope must be* >> *serializable.* >> >> >> The Weld documentation is a bit more explicit : >> >> *5.2. Built-in scopes* >> *Managed beans with scope @SessionScoped or @ConversationScoped must be >> serializable, since the container passivates the HTTP session from time to >> time.* >> >> >> And in the Java EE Tutorial we find ( >> http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >> >> *Beans that use session, application, or conversation scope must be >> serializable*, but beans that use request scope do not have to be >> serializable. >> >> >> This even made be doubt about the application scope ?!? >> >> >> Any way, could we clarify this in the CDI spec ? >> >> >> -- >> 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 listcdi-dev at lists.jboss.orghttps://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/20150202/5b1b70e2/attachment.html From rmannibucau at gmail.com Mon Feb 2 10:21:59 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 2 Feb 2015 16:21:59 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <54CF9356.5060106@redhat.com> References: <54CF9356.5060106@redhat.com> Message-ID: @Jozef: yes or no but supposing it it leads to the same result. Typically the case I care here is default tomcat one (+ embedded tomcat* ones) where session is never serialized so this constraint is not needed at all. That said having a SPI to add a serializer by bean (or default one) to avoid this constraint is awesome as well. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-02 16:10 GMT+01:00 Jozef Hartinger : > Can you elaborate? If a bean has a normal scope (passivating), it may need > to be passivated. Are you talking about using a serialization tool that does > not require objects to implement Serializable and using such tool to > passivate a context? > > Jozef > > > On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: > > Hi > > +1 to clarify it. All normal scope dont need Serializable constraint - even > session scope - and it makes sense to not respect it in a lot of apps > without preventing these beans to be serializable thans their proxies. > > Best IMO is to either remove it or to allow a scope serializer service to be > specified to keep it portable. > > Wdyt? > > Le 1 f?vr. 2015 13:36, "Antonio Goncalves" a > ?crit : >> >> Hi all, >> >> I was reading the CDI 1.2 spec and couldn't clearly find the way >> serialization and scopes work. The only explicit sentence I found was : >> >> >> 1.3.1. JSF example >> The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope >> types? is a scope >> type that specifies the lifecycle of instances of Login. Managed beans >> with this scope must be >> serializable. >> >> >> The Weld documentation is a bit more explicit : >> >> 5.2. Built-in scopes >> Managed beans with scope @SessionScoped or @ConversationScoped must be >> serializable, since the container passivates the HTTP session from time to >> time. >> >> >> And in the Java EE Tutorial we find >> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >> >> Beans that use session, application, or conversation scope must be >> serializable, but beans that use request scope do not have to be >> serializable. >> >> >> This even made be doubt about the application scope ?!? >> >> >> Any way, could we clarify this in the CDI spec ? >> >> >> -- >> 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. > > From struberg at yahoo.de Mon Feb 2 10:38:42 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 2 Feb 2015 15:38:42 +0000 (UTC) Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <1557185184.1058637.1422891522399.JavaMail.yahoo@mail.yahoo.com> Romain, that's not true. Tomcat by default ALWAYS serializes the session at shutdown! Even if you don't have a cluster set up. This is also required by the Servlets spec... LieGrue, strub > On Monday, 2 February 2015, 16:23, Romain Manni-Bucau wrote: > > @Jozef: yes or no but supposing it it leads to the same result. > Typically the case I care here is default tomcat one (+ embedded > tomcat* ones) where session is never serialized so this constraint is > not needed at all. That said having a SPI to add a serializer by bean > (or default one) to avoid this constraint is awesome as well. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-02-02 16:10 GMT+01:00 Jozef Hartinger : >> Can you elaborate? If a bean has a normal scope (passivating), it may need >> to be passivated. Are you talking about using a serialization tool that > does >> not require objects to implement Serializable and using such tool to >> passivate a context? >> >> Jozef >> >> >> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >> >> Hi >> >> +1 to clarify it. All normal scope dont need Serializable constraint - even >> session scope - and it makes sense to not respect it in a lot of apps >> without preventing these beans to be serializable thans their proxies. >> >> Best IMO is to either remove it or to allow a scope serializer service to > be >> specified to keep it portable. >> >> Wdyt? >> >> Le 1 f?vr. 2015 13:36, "Antonio Goncalves" > a >> ?crit : >>> >>> Hi all, >>> >>> I was reading the CDI 1.2 spec and couldn't clearly find the way >>> serialization and scopes work. The only explicit sentence I found was : >>> >>> >>> 1.3.1. JSF example >>> The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope >>> types? is a scope >>> type that specifies the lifecycle of instances of Login. Managed beans >>> with this scope must be >>> serializable. >>> >>> >>> The Weld documentation is a bit more explicit : >>> >>> 5.2. Built-in scopes >>> Managed beans with scope @SessionScoped or @ConversationScoped must be >>> serializable, since the container passivates the HTTP session from time > to >>> time. >>> >>> >>> And in the Java EE Tutorial we find >>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>> >>> Beans that use session, application, or conversation scope must be >>> serializable, but beans that use request scope do not have to be >>> serializable. >>> >>> >>> This even made be doubt about the application scope ?!? >>> >>> >>> Any way, could we clarify this in the CDI spec ? >>> >>> >>> -- >>> 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. >> >> > > _______________________________________________ > 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 Mon Feb 2 10:41:44 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 2 Feb 2015 16:41:44 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <1557185184.1058637.1422891522399.JavaMail.yahoo@mail.yahoo.com> References: <1557185184.1058637.1422891522399.JavaMail.yahoo@mail.yahoo.com> Message-ID: @Mark: that's not true. 1) you can switch it off + I mainly spoke of embedded case where it is true in 80% of cases Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-02 16:38 GMT+01:00 Mark Struberg : > Romain, that's not true. Tomcat by default ALWAYS serializes the session at shutdown! Even if you don't have a cluster set up. This is also required by the Servlets spec... > > LieGrue, > strub > > > > > >> On Monday, 2 February 2015, 16:23, Romain Manni-Bucau wrote: >> > @Jozef: yes or no but supposing it it leads to the same result. >> Typically the case I care here is default tomcat one (+ embedded >> tomcat* ones) where session is never serialized so this constraint is >> not needed at all. That said having a SPI to add a serializer by bean >> (or default one) to avoid this constraint is awesome as well. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> >> 2015-02-02 16:10 GMT+01:00 Jozef Hartinger : >>> Can you elaborate? If a bean has a normal scope (passivating), it may need >>> to be passivated. Are you talking about using a serialization tool that >> does >>> not require objects to implement Serializable and using such tool to >>> passivate a context? >>> >>> Jozef >>> >>> >>> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >>> >>> Hi >>> >>> +1 to clarify it. All normal scope dont need Serializable constraint - even >>> session scope - and it makes sense to not respect it in a lot of apps >>> without preventing these beans to be serializable thans their proxies. >>> >>> Best IMO is to either remove it or to allow a scope serializer service to >> be >>> specified to keep it portable. >>> >>> Wdyt? >>> >>> Le 1 f?vr. 2015 13:36, "Antonio Goncalves" >> a >>> ?crit : >>>> >>>> Hi all, >>>> >>>> I was reading the CDI 1.2 spec and couldn't clearly find the way >>>> serialization and scopes work. The only explicit sentence I found was : >>>> >>>> >>>> 1.3.1. JSF example >>>> The @SessionScoped annotation defined in Section 2.4.1, ?Built-in scope >>>> types? is a scope >>>> type that specifies the lifecycle of instances of Login. Managed beans >>>> with this scope must be >>>> serializable. >>>> >>>> >>>> The Weld documentation is a bit more explicit : >>>> >>>> 5.2. Built-in scopes >>>> Managed beans with scope @SessionScoped or @ConversationScoped must be >>>> serializable, since the container passivates the HTTP session from time >> to >>>> time. >>>> >>>> >>>> And in the Java EE Tutorial we find >>>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>>> >>>> Beans that use session, application, or conversation scope must be >>>> serializable, but beans that use request scope do not have to be >>>> serializable. >>>> >>>> >>>> This even made be doubt about the application scope ?!? >>>> >>>> >>>> Any way, could we clarify this in the CDI spec ? >>>> >>>> >>>> -- >>>> 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. >>> >>> >> >> _______________________________________________ >> 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 struberg at yahoo.de Mon Feb 2 10:50:05 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 2 Feb 2015 15:50:05 +0000 (UTC) Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <620855381.1072558.1422892205935.JavaMail.yahoo@mail.yahoo.com> but you HAVE to manually switch it off. By _default_ the serialization is on... LieGrue, strub > On Monday, 2 February 2015, 16:42, Romain Manni-Bucau wrote: > > @Mark: that's not true. 1) you can switch it off + I mainly spoke of > embedded case where it is true in 80% of cases > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-02-02 16:38 GMT+01:00 Mark Struberg : >> Romain, that's not true. Tomcat by default ALWAYS serializes the > session at shutdown! Even if you don't have a cluster set up. This is also > required by the Servlets spec... >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 2 February 2015, 16:23, Romain Manni-Bucau > wrote: >>> > @Jozef: yes or no but supposing it it leads to the same result. >>> Typically the case I care here is default tomcat one (+ embedded >>> tomcat* ones) where session is never serialized so this constraint is >>> not needed at all. That said having a SPI to add a serializer by bean >>> (or default one) to avoid this constraint is awesome as well. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> >>> 2015-02-02 16:10 GMT+01:00 Jozef Hartinger : >>>> Can you elaborate? If a bean has a normal scope (passivating), it > may need >>>> to be passivated. Are you talking about using a serialization tool > that >>> does >>>> not require objects to implement Serializable and using such tool > to >>>> passivate a context? >>>> >>>> Jozef >>>> >>>> >>>> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >>>> >>>> Hi >>>> >>>> +1 to clarify it. All normal scope dont need Serializable > constraint - even >>>> session scope - and it makes sense to not respect it in a lot of > apps >>>> without preventing these beans to be serializable thans their > proxies. >>>> >>>> Best IMO is to either remove it or to allow a scope serializer > service to >>> be >>>> specified to keep it portable. >>>> >>>> Wdyt? >>>> >>>> Le 1 f?vr. 2015 13:36, "Antonio Goncalves" >>> a >>>> ?crit : >>>>> >>>>> Hi all, >>>>> >>>>> I was reading the CDI 1.2 spec and couldn't clearly find > the way >>>>> serialization and scopes work. The only explicit sentence I > found was : >>>>> >>>>> >>>>> 1.3.1. JSF example >>>>> The @SessionScoped annotation defined in Section 2.4.1, > ?Built-in scope >>>>> types? is a scope >>>>> type that specifies the lifecycle of instances of Login. > Managed beans >>>>> with this scope must be >>>>> serializable. >>>>> >>>>> >>>>> The Weld documentation is a bit more explicit : >>>>> >>>>> 5.2. Built-in scopes >>>>> Managed beans with scope @SessionScoped or @ConversationScoped > must be >>>>> serializable, since the container passivates the HTTP session > from time >>> to >>>>> time. >>>>> >>>>> >>>>> And in the Java EE Tutorial we find >>>>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>>>> >>>>> Beans that use session, application, or conversation scope > must be >>>>> serializable, but beans that use request scope do not have to > be >>>>> serializable. >>>>> >>>>> >>>>> This even made be doubt about the application scope ?!? >>>>> >>>>> >>>>> Any way, could we clarify this in the CDI spec ? >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>> >>> _______________________________________________ >>> 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 Mon Feb 2 10:50:44 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 2 Feb 2015 16:50:44 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <620855381.1072558.1422892205935.JavaMail.yahoo@mail.yahoo.com> References: <620855381.1072558.1422892205935.JavaMail.yahoo@mail.yahoo.com> Message-ID: in a standard tomcat yes but not in most of embedded ones...and that's not the point anyway Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-02 16:50 GMT+01:00 Mark Struberg : > but you HAVE to manually switch it off. By _default_ the serialization is on... > > LieGrue, > strub > > > > >> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau wrote: >> > @Mark: that's not true. 1) you can switch it off + I mainly spoke of >> embedded case where it is true in 80% of cases >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> >> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >>> Romain, that's not true. Tomcat by default ALWAYS serializes the >> session at shutdown! Even if you don't have a cluster set up. This is also >> required by the Servlets spec... >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 2 February 2015, 16:23, Romain Manni-Bucau >> wrote: >>>> > @Jozef: yes or no but supposing it it leads to the same result. >>>> Typically the case I care here is default tomcat one (+ embedded >>>> tomcat* ones) where session is never serialized so this constraint is >>>> not needed at all. That said having a SPI to add a serializer by bean >>>> (or default one) to avoid this constraint is awesome as well. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> >>>> 2015-02-02 16:10 GMT+01:00 Jozef Hartinger : >>>>> Can you elaborate? If a bean has a normal scope (passivating), it >> may need >>>>> to be passivated. Are you talking about using a serialization tool >> that >>>> does >>>>> not require objects to implement Serializable and using such tool >> to >>>>> passivate a context? >>>>> >>>>> Jozef >>>>> >>>>> >>>>> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >>>>> >>>>> Hi >>>>> >>>>> +1 to clarify it. All normal scope dont need Serializable >> constraint - even >>>>> session scope - and it makes sense to not respect it in a lot of >> apps >>>>> without preventing these beans to be serializable thans their >> proxies. >>>>> >>>>> Best IMO is to either remove it or to allow a scope serializer >> service to >>>> be >>>>> specified to keep it portable. >>>>> >>>>> Wdyt? >>>>> >>>>> Le 1 f?vr. 2015 13:36, "Antonio Goncalves" >>>> a >>>>> ?crit : >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I was reading the CDI 1.2 spec and couldn't clearly find >> the way >>>>>> serialization and scopes work. The only explicit sentence I >> found was : >>>>>> >>>>>> >>>>>> 1.3.1. JSF example >>>>>> The @SessionScoped annotation defined in Section 2.4.1, >> ?Built-in scope >>>>>> types? is a scope >>>>>> type that specifies the lifecycle of instances of Login. >> Managed beans >>>>>> with this scope must be >>>>>> serializable. >>>>>> >>>>>> >>>>>> The Weld documentation is a bit more explicit : >>>>>> >>>>>> 5.2. Built-in scopes >>>>>> Managed beans with scope @SessionScoped or @ConversationScoped >> must be >>>>>> serializable, since the container passivates the HTTP session >> from time >>>> to >>>>>> time. >>>>>> >>>>>> >>>>>> And in the Java EE Tutorial we find >>>>>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>>>>> >>>>>> Beans that use session, application, or conversation scope >> must be >>>>>> serializable, but beans that use request scope do not have to >> be >>>>>> serializable. >>>>>> >>>>>> >>>>>> This even made be doubt about the application scope ?!? >>>>>> >>>>>> >>>>>> Any way, could we clarify this in the CDI spec ? >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 jharting at redhat.com Tue Feb 3 03:39:09 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 03 Feb 2015 09:39:09 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> References: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> Message-ID: <54D0892D.108@redhat.com> We should enumerate all the arguments supporting async flag on an observer. So far I have only seen one: - an observer accessing @RequestScoped state would no longer be able to do so since it would be run in a worker thread I am eager to hear more arguments as this single one may not be enough to justify the observer-async-flag design decision. Remember that introducing fireAsync() itself does not break any existing application because existing applications are using fire(). It's when an existing application / library is modified to use fireAsync() when the problem may occur. Such change should not be done blindly. As with any other change, an author should consider possible consequences of the change. Clearly documenting the fact that fireAsync() processing is done in a different thread with a different @RequestScoped state may be sufficient. Jozef On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: > Hi all, > > > https://issues.jboss.org/browse/CDI-499 comes after a lot of > discussion about async events. > > I think the solution exposed here is quite satisfying, yet the idea to > need to activate async behaviour on the observer side doesn?t please a > lot of us. It?ll be confusing for users to have to activate async from > the firing end and consuming end to see it work :-(. > > I?d like to see alternative proposal to have this new feature as user > friendly as possible and keep the retro-compatibility aspect. We > should find a better solution on our next meeting on wednesday. > > 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/20150203/06b21b32/attachment-0001.html From antoine at sabot-durand.net Tue Feb 3 03:55:55 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 3 Feb 2015 09:55:55 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54D0892D.108@redhat.com> References: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> <54D0892D.108@redhat.com> Message-ID: <6BD81908-F786-490C-B0C0-E39661ABFECD@sabot-durand.net> Thanks Jozef, You?re right. The best solution would be to prove that this doesn?t break backward compatibility. I had the same feeling than you but I?d like the majority of us to agree with this approach. Antoine > Le 3 f?vr. 2015 ? 09:39, Jozef Hartinger a ?crit : > > We should enumerate all the arguments supporting async flag on an observer. So far I have only seen one: > > - an observer accessing @RequestScoped state would no longer be able to do so since it would be run in a worker thread > > I am eager to hear more arguments as this single one may not be enough to justify the observer-async-flag design decision. > > Remember that introducing fireAsync() itself does not break any existing application because existing applications are using fire(). It's when an existing application / library is modified to use fireAsync() when the problem may occur. Such change should not be done blindly. As with any other change, an author should consider possible consequences of the change. Clearly documenting the fact that fireAsync() processing is done in a different thread with a different @RequestScoped state may be sufficient. > > Jozef > > On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >> Hi all, >> >> >> https://issues.jboss.org/browse/CDI-499 comes after a lot of discussion about async events. >> >> I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn?t please a lot of us. It?ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(. >> >> I?d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday. >> >> 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/20150203/bbabe266/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150203/bbabe266/attachment.bin From werner.keil at gmail.com Tue Feb 3 04:59:51 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 3 Feb 2015 10:59:51 +0100 Subject: [cdi-dev] Clarify scopes and serialization Message-ID: What about TomEE? After all it's Java EE 6 certified: http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html So as Mark mentioned briefly, there is a requirement by the Servlet spec, so I assume it is either always on or at least on by default (otherwise a TomEE "tweaked" like that would no longer be Java EE compliant;-) Tomcat itself was never certified. Werner On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) > 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) > 3. Re: Clarify scopes and serialization (Mark Struberg) > 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) > 5. Re: Async events. We need ideas to improve CDI-499 > (Jozef Hartinger) > > > ---------------------------------------------------------------------- > > > Message: 4 > Date: Mon, 2 Feb 2015 16:50:44 +0100 > From: Romain Manni-Bucau > Subject: Re: [cdi-dev] Clarify scopes and serialization > To: Mark Struberg > Cc: cdi-dev > Message-ID: > 7MUGeq_bgdx0W_hPT-15-9ae_XdD3kab0P3vE4YHftKRg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > in a standard tomcat yes but not in most of embedded ones...and that's > not the point anyway > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-02 16:50 GMT+01:00 Mark Struberg : > > but you HAVE to manually switch it off. By _default_ the serialization > is on... > > > > LieGrue, > > strub > > > > > > > > > >> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >> > @Mark: that's not true. 1) you can switch it off + I mainly spoke of > >> embedded case where it is true in 80% of cases > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> > >> 2015-02-02 16:38 GMT+01:00 Mark Struberg : > >>> Romain, that's not true. Tomcat by default ALWAYS serializes the > >> session at shutdown! Even if you don't have a cluster set up. This is > also > >> required by the Servlets spec... > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > _______________________________________________ > 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 51, Issue 4 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150203/7668d1a5/attachment.html From rmannibucau at gmail.com Tue Feb 3 05:03:00 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 3 Feb 2015 11:03:00 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: servlet spec requirement is only for distributed systems AFAIK == not required in most of instances. tomee supports both and is aligned on tomcat for all tomee flavors and is serialization-less in openejb flavors That said this is not a certification question but a usage question Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-03 10:59 GMT+01:00 Werner Keil : > What about TomEE? > After all it's Java EE 6 certified: > http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html > > So as Mark mentioned briefly, there is a requirement by the Servlet spec, so > I assume it is either always on or at least on by default (otherwise a TomEE > "tweaked" like that would no longer be Java EE compliant;-) > > Tomcat itself was never certified. > > Werner > > > On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> 3. Re: Clarify scopes and serialization (Mark Struberg) >> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> 5. Re: Async events. We need ideas to improve CDI-499 >> (Jozef Hartinger) >> >> >> ---------------------------------------------------------------------- >> >> >> Message: 4 >> Date: Mon, 2 Feb 2015 16:50:44 +0100 >> From: Romain Manni-Bucau >> Subject: Re: [cdi-dev] Clarify scopes and serialization >> To: Mark Struberg >> Cc: cdi-dev >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> in a standard tomcat yes but not in most of embedded ones...and that's >> not the point anyway >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >> > but you HAVE to manually switch it off. By _default_ the serialization >> > is on... >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> >> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >> >> wrote: >> >> > @Mark: that's not true. 1) you can switch it off + I mainly spoke of >> >> embedded case where it is true in 80% of cases >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >> >>> Romain, that's not true. Tomcat by default ALWAYS serializes the >> >> session at shutdown! Even if you don't have a cluster set up. This is >> >> also >> >> required by the Servlets spec... >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> _______________________________________________ >> 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 51, Issue 4 >> ************************************** > > > > _______________________________________________ > 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 werner.keil at gmail.com Tue Feb 3 05:13:16 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 3 Feb 2015 11:13:16 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: Mark might know in more detail, he brought it up. As both EC and EE (6-8) JSR Member I certainly have a lot to do with this, but neither is responsible for details of product certification;-) Werner On Tue, Feb 3, 2015 at 11:03 AM, Romain Manni-Bucau wrote: > servlet spec requirement is only for distributed systems AFAIK == not > required in most of instances. > tomee supports both and is aligned on tomcat for all tomee flavors and > is serialization-less in openejb flavors > > That said this is not a certification question but a usage question > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-03 10:59 GMT+01:00 Werner Keil : > > What about TomEE? > > After all it's Java EE 6 certified: > > > http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html > > > > So as Mark mentioned briefly, there is a requirement by the Servlet > spec, so > > I assume it is either always on or at least on by default (otherwise a > TomEE > > "tweaked" like that would no longer be Java EE compliant;-) > > > > Tomcat itself was never certified. > > > > Werner > > > > > > On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) > >> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >> 3. Re: Clarify scopes and serialization (Mark Struberg) > >> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >> 5. Re: Async events. We need ideas to improve CDI-499 > >> (Jozef Hartinger) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> > >> Message: 4 > >> Date: Mon, 2 Feb 2015 16:50:44 +0100 > >> From: Romain Manni-Bucau > >> Subject: Re: [cdi-dev] Clarify scopes and serialization > >> To: Mark Struberg > >> Cc: cdi-dev > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> in a standard tomcat yes but not in most of embedded ones...and that's > >> not the point anyway > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-02 16:50 GMT+01:00 Mark Struberg : > >> > but you HAVE to manually switch it off. By _default_ the serialization > >> > is on... > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > >> > > >> >> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau > >> >> wrote: > >> >> > @Mark: that's not true. 1) you can switch it off + I mainly spoke > of > >> >> embedded case where it is true in 80% of cases > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> > >> >> 2015-02-02 16:38 GMT+01:00 Mark Struberg : > >> >>> Romain, that's not true. Tomcat by default ALWAYS serializes the > >> >> session at shutdown! Even if you don't have a cluster set up. This is > >> >> also > >> >> required by the Servlets spec... > >> >>> > >> >>> LieGrue, > >> >>> strub > >> >>> > >> >>> > >> >>> > >> _______________________________________________ > >> 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 51, Issue 4 > >> ************************************** > > > > > > > > _______________________________________________ > > 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/20150203/ec679fdb/attachment-0001.html From rmannibucau at gmail.com Tue Feb 3 05:14:38 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 3 Feb 2015 11:14:38 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: @Werner: can you explain your point, I dont get it, you keep speaking about certification and it is not my point at all. Being certified is good but better is to be usable Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-03 11:13 GMT+01:00 Werner Keil : > Mark might know in more detail, he brought it up. > > As both EC and EE (6-8) JSR Member I certainly have a lot to do with this, > but neither is responsible for details of product certification;-) > > Werner > > > On Tue, Feb 3, 2015 at 11:03 AM, Romain Manni-Bucau > wrote: >> >> servlet spec requirement is only for distributed systems AFAIK == not >> required in most of instances. >> tomee supports both and is aligned on tomcat for all tomee flavors and >> is serialization-less in openejb flavors >> >> That said this is not a certification question but a usage question >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-03 10:59 GMT+01:00 Werner Keil : >> > What about TomEE? >> > After all it's Java EE 6 certified: >> > >> > http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html >> > >> > So as Mark mentioned briefly, there is a requirement by the Servlet >> > spec, so >> > I assume it is either always on or at least on by default (otherwise a >> > TomEE >> > "tweaked" like that would no longer be Java EE compliant;-) >> > >> > Tomcat itself was never certified. >> > >> > Werner >> > >> > >> > On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >> >> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> >> 3. Re: Clarify scopes and serialization (Mark Struberg) >> >> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> >> 5. Re: Async events. We need ideas to improve CDI-499 >> >> (Jozef Hartinger) >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> Message: 4 >> >> Date: Mon, 2 Feb 2015 16:50:44 +0100 >> >> From: Romain Manni-Bucau >> >> Subject: Re: [cdi-dev] Clarify scopes and serialization >> >> To: Mark Struberg >> >> Cc: cdi-dev >> >> Message-ID: >> >> >> >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> >> >> >> in a standard tomcat yes but not in most of embedded ones...and that's >> >> not the point anyway >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >> >> > but you HAVE to manually switch it off. By _default_ the >> >> > serialization >> >> > is on... >> >> > >> >> > LieGrue, >> >> > strub >> >> > >> >> > >> >> > >> >> > >> >> >> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >> >> >> wrote: >> >> >> > @Mark: that's not true. 1) you can switch it off + I mainly spoke >> >> >> > of >> >> >> embedded case where it is true in 80% of cases >> >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> >> @rmannibucau >> >> >> http://www.tomitribe.com >> >> >> http://rmannibucau.wordpress.com >> >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> >> >> >> >> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >> >> >>> Romain, that's not true. Tomcat by default ALWAYS serializes the >> >> >> session at shutdown! Even if you don't have a cluster set up. This >> >> >> is >> >> >> also >> >> >> required by the Servlets spec... >> >> >>> >> >> >>> LieGrue, >> >> >>> strub >> >> >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >> >> 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 51, Issue 4 >> >> ************************************** >> > >> > >> > >> > _______________________________________________ >> > 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 jharting at redhat.com Tue Feb 3 05:17:06 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 03 Feb 2015 11:17:06 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: Message-ID: <54D0A022.1020104@redhat.com> If we want applications to be portable across different implementations then the spec should require the least common multiple - that is beans that belong to passivating scopes being serializable. TomEE/OWB is free to have a mode in which passivation requirements are not checked if the server runs in non-passivating mode. On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: > servlet spec requirement is only for distributed systems AFAIK == not > required in most of instances. > tomee supports both and is aligned on tomcat for all tomee flavors and > is serialization-less in openejb flavors > > That said this is not a certification question but a usage question > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-03 10:59 GMT+01:00 Werner Keil : >> What about TomEE? >> After all it's Java EE 6 certified: >> http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html >> >> So as Mark mentioned briefly, there is a requirement by the Servlet spec, so >> I assume it is either always on or at least on by default (otherwise a TomEE >> "tweaked" like that would no longer be Java EE compliant;-) >> >> Tomcat itself was never certified. >> >> Werner >> >> >> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>> 3. Re: Clarify scopes and serialization (Mark Struberg) >>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>> 5. Re: Async events. We need ideas to improve CDI-499 >>> (Jozef Hartinger) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> >>> Message: 4 >>> Date: Mon, 2 Feb 2015 16:50:44 +0100 >>> From: Romain Manni-Bucau >>> Subject: Re: [cdi-dev] Clarify scopes and serialization >>> To: Mark Struberg >>> Cc: cdi-dev >>> Message-ID: >>> >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> >>> in a standard tomcat yes but not in most of embedded ones...and that's >>> not the point anyway >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >>>> but you HAVE to manually switch it off. By _default_ the serialization >>>> is on... >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >>>>> wrote: >>>>>> @Mark: that's not true. 1) you can switch it off + I mainly spoke of >>>>> embedded case where it is true in 80% of cases >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> >>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes the >>>>> session at shutdown! Even if you don't have a cluster set up. This is >>>>> also >>>>> required by the Servlets spec... >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> 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 51, Issue 4 >>> ************************************** >> >> >> _______________________________________________ >> 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 werner.keil at gmail.com Tue Feb 3 05:22:05 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 3 Feb 2015 11:22:05 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: <54D0A022.1020104@redhat.com> References: <54D0A022.1020104@redhat.com> Message-ID: Guess Jozef pretty much hit the point, I don't care about the sticker or label you may put on your laptop or product, but a compatible behavior allowing users to deploy against as many available containers as possible with minimal or no changes at all;-) On Tue, Feb 3, 2015 at 11:17 AM, Jozef Hartinger wrote: > If we want applications to be portable across different implementations > then the spec should require the least common multiple - that is beans that > belong to passivating scopes being serializable. TomEE/OWB is free to have > a mode in which passivation requirements are not checked if the server runs > in non-passivating mode. > > > On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: > >> servlet spec requirement is only for distributed systems AFAIK == not >> required in most of instances. >> tomee supports both and is aligned on tomcat for all tomee flavors and >> is serialization-less in openejb flavors >> >> That said this is not a certification question but a usage question >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-03 10:59 GMT+01:00 Werner Keil : >> >>> What about TomEE? >>> After all it's Java EE 6 certified: >>> http://www.oracle.com/technetwork/java/javaee/ >>> overview/compatibility-jsp-136984.html >>> >>> So as Mark mentioned briefly, there is a requirement by the Servlet >>> spec, so >>> I assume it is either always on or at least on by default (otherwise a >>> TomEE >>> "tweaked" like that would no longer be Java EE compliant;-) >>> >>> Tomcat itself was never certified. >>> >>> Werner >>> >>> >>> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >>>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>>> 3. Re: Clarify scopes and serialization (Mark Struberg) >>>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>>> 5. Re: Async events. We need ideas to improve CDI-499 >>>> (Jozef Hartinger) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> Message: 4 >>>> Date: Mon, 2 Feb 2015 16:50:44 +0100 >>>> From: Romain Manni-Bucau >>>> Subject: Re: [cdi-dev] Clarify scopes and serialization >>>> To: Mark Struberg >>>> Cc: cdi-dev >>>> Message-ID: >>>> >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> in a standard tomcat yes but not in most of embedded ones...and that's >>>> not the point anyway >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >>>> >>>>> but you HAVE to manually switch it off. By _default_ the serialization >>>>> is on... >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>>> @Mark: that's not true. 1) you can switch it off + I mainly spoke of >>>>>>> >>>>>> embedded case where it is true in 80% of cases >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> >>>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >>>>>> >>>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes the >>>>>>> >>>>>> session at shutdown! Even if you don't have a cluster set up. This is >>>>>> also >>>>>> required by the Servlets spec... >>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>> 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 51, Issue 4 >>>> ************************************** >>>> >>> >>> >>> _______________________________________________ >>> 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/20150203/582f4d54/attachment-0001.html From rmannibucau at gmail.com Tue Feb 3 05:24:22 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 3 Feb 2015 11:24:22 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: <54D0A022.1020104@redhat.com> Message-ID: point is while serialization itself is not specified you have no more guarantee with Serializable. ATM you can serialize your bean passivationId and keep your bean instance in memory (in a map). You didnt serialize anything excepted a string! So why forcing such a constraint if it is an implementation detail? Serialization process is not explicit so then constraint doesnt guarantee any portability Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-03 11:22 GMT+01:00 Werner Keil : > Guess Jozef pretty much hit the point, I don't care about the sticker or > label you may put on your laptop or product, but a compatible behavior > allowing users to deploy against as many available containers as possible > with minimal or no changes at all;-) > > On Tue, Feb 3, 2015 at 11:17 AM, Jozef Hartinger > wrote: >> >> If we want applications to be portable across different implementations >> then the spec should require the least common multiple - that is beans that >> belong to passivating scopes being serializable. TomEE/OWB is free to have a >> mode in which passivation requirements are not checked if the server runs in >> non-passivating mode. >> >> >> On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: >>> >>> servlet spec requirement is only for distributed systems AFAIK == not >>> required in most of instances. >>> tomee supports both and is aligned on tomcat for all tomee flavors and >>> is serialization-less in openejb flavors >>> >>> That said this is not a certification question but a usage question >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-03 10:59 GMT+01:00 Werner Keil : >>>> >>>> What about TomEE? >>>> After all it's Java EE 6 certified: >>>> >>>> http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html >>>> >>>> So as Mark mentioned briefly, there is a requirement by the Servlet >>>> spec, so >>>> I assume it is either always on or at least on by default (otherwise a >>>> TomEE >>>> "tweaked" like that would no longer be Java EE compliant;-) >>>> >>>> Tomcat itself was never certified. >>>> >>>> Werner >>>> >>>> >>>> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >>>>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>>>> 3. Re: Clarify scopes and serialization (Mark Struberg) >>>>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >>>>> 5. Re: Async events. We need ideas to improve CDI-499 >>>>> (Jozef Hartinger) >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> Message: 4 >>>>> Date: Mon, 2 Feb 2015 16:50:44 +0100 >>>>> From: Romain Manni-Bucau >>>>> Subject: Re: [cdi-dev] Clarify scopes and serialization >>>>> To: Mark Struberg >>>>> Cc: cdi-dev >>>>> Message-ID: >>>>> >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> in a standard tomcat yes but not in most of embedded ones...and that's >>>>> not the point anyway >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >>>>>> >>>>>> but you HAVE to manually switch it off. By _default_ the serialization >>>>>> is on... >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >>>>>>> wrote: >>>>>>>> >>>>>>>> @Mark: that's not true. 1) you can switch it off + I mainly spoke of >>>>>>> >>>>>>> embedded case where it is true in 80% of cases >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau >>>>>>> http://www.tomitribe.com >>>>>>> http://rmannibucau.wordpress.com >>>>>>> https://github.com/rmannibucau >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >>>>>>>> >>>>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes the >>>>>>> >>>>>>> session at shutdown! Even if you don't have a cluster set up. This is >>>>>>> also >>>>>>> required by the Servlets spec... >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> 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 51, Issue 4 >>>>> ************************************** >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 werner.keil at gmail.com Tue Feb 3 05:30:05 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 3 Feb 2015 11:30:05 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: <54D0A022.1020104@redhat.com> Message-ID: That you'd have to ask the Servlet Spec Leads: https://jcp.org/en/jsr/detail?id=369 As of now, it seems Tomitribe has no EG Member there, but I'm sure you could discuss anything with them if you feel it is a burden or makes no sense;-) Werner On Tue, Feb 3, 2015 at 11:24 AM, Romain Manni-Bucau wrote: > point is while serialization itself is not specified you have no more > guarantee with Serializable. ATM you can serialize your bean > passivationId and keep your bean instance in memory (in a map). You > didnt serialize anything excepted a string! > > So why forcing such a constraint if it is an implementation detail? > Serialization process is not explicit so then constraint doesnt > guarantee any portability > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-03 11:22 GMT+01:00 Werner Keil : > > Guess Jozef pretty much hit the point, I don't care about the sticker or > > label you may put on your laptop or product, but a compatible behavior > > allowing users to deploy against as many available containers as possible > > with minimal or no changes at all;-) > > > > On Tue, Feb 3, 2015 at 11:17 AM, Jozef Hartinger > > wrote: > >> > >> If we want applications to be portable across different implementations > >> then the spec should require the least common multiple - that is beans > that > >> belong to passivating scopes being serializable. TomEE/OWB is free to > have a > >> mode in which passivation requirements are not checked if the server > runs in > >> non-passivating mode. > >> > >> > >> On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: > >>> > >>> servlet spec requirement is only for distributed systems AFAIK == not > >>> required in most of instances. > >>> tomee supports both and is aligned on tomcat for all tomee flavors and > >>> is serialization-less in openejb flavors > >>> > >>> That said this is not a certification question but a usage question > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-03 10:59 GMT+01:00 Werner Keil : > >>>> > >>>> What about TomEE? > >>>> After all it's Java EE 6 certified: > >>>> > >>>> > http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html > >>>> > >>>> So as Mark mentioned briefly, there is a requirement by the Servlet > >>>> spec, so > >>>> I assume it is either always on or at least on by default (otherwise a > >>>> TomEE > >>>> "tweaked" like that would no longer be Java EE compliant;-) > >>>> > >>>> Tomcat itself was never certified. > >>>> > >>>> Werner > >>>> > >>>> > >>>> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) > >>>>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >>>>> 3. Re: Clarify scopes and serialization (Mark Struberg) > >>>>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >>>>> 5. Re: Async events. We need ideas to improve CDI-499 > >>>>> (Jozef Hartinger) > >>>>> > >>>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> > >>>>> > >>>>> Message: 4 > >>>>> Date: Mon, 2 Feb 2015 16:50:44 +0100 > >>>>> From: Romain Manni-Bucau > >>>>> Subject: Re: [cdi-dev] Clarify scopes and serialization > >>>>> To: Mark Struberg > >>>>> Cc: cdi-dev > >>>>> Message-ID: > >>>>> > >>>>> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> in a standard tomcat yes but not in most of embedded ones...and > that's > >>>>> not the point anyway > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> @rmannibucau > >>>>> http://www.tomitribe.com > >>>>> http://rmannibucau.wordpress.com > >>>>> https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : > >>>>>> > >>>>>> but you HAVE to manually switch it off. By _default_ the > serialization > >>>>>> is on... > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> @Mark: that's not true. 1) you can switch it off + I mainly spoke > of > >>>>>>> > >>>>>>> embedded case where it is true in 80% of cases > >>>>>>> > >>>>>>> > >>>>>>> Romain Manni-Bucau > >>>>>>> @rmannibucau > >>>>>>> http://www.tomitribe.com > >>>>>>> http://rmannibucau.wordpress.com > >>>>>>> https://github.com/rmannibucau > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : > >>>>>>>> > >>>>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes the > >>>>>>> > >>>>>>> session at shutdown! Even if you don't have a cluster set up. This > is > >>>>>>> also > >>>>>>> required by the Servlets spec... > >>>>>>>> > >>>>>>>> LieGrue, > >>>>>>>> strub > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> _______________________________________________ > >>>>> 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 51, Issue 4 > >>>>> ************************************** > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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/20150203/edcacd93/attachment-0001.html From rmannibucau at gmail.com Tue Feb 3 05:30:51 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 3 Feb 2015 11:30:51 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: <54D0A022.1020104@redhat.com> Message-ID: still dont get why you keep saying servlet spec assume serialization... Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-03 11:30 GMT+01:00 Werner Keil : > That you'd have to ask the Servlet Spec Leads: > https://jcp.org/en/jsr/detail?id=369 > As of now, it seems Tomitribe has no EG Member there, but I'm sure you could > discuss anything with them if you feel it is a burden or makes no sense;-) > > Werner > > > On Tue, Feb 3, 2015 at 11:24 AM, Romain Manni-Bucau > wrote: >> >> point is while serialization itself is not specified you have no more >> guarantee with Serializable. ATM you can serialize your bean >> passivationId and keep your bean instance in memory (in a map). You >> didnt serialize anything excepted a string! >> >> So why forcing such a constraint if it is an implementation detail? >> Serialization process is not explicit so then constraint doesnt >> guarantee any portability >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-03 11:22 GMT+01:00 Werner Keil : >> > Guess Jozef pretty much hit the point, I don't care about the sticker or >> > label you may put on your laptop or product, but a compatible behavior >> > allowing users to deploy against as many available containers as >> > possible >> > with minimal or no changes at all;-) >> > >> > On Tue, Feb 3, 2015 at 11:17 AM, Jozef Hartinger >> > wrote: >> >> >> >> If we want applications to be portable across different implementations >> >> then the spec should require the least common multiple - that is beans >> >> that >> >> belong to passivating scopes being serializable. TomEE/OWB is free to >> >> have a >> >> mode in which passivation requirements are not checked if the server >> >> runs in >> >> non-passivating mode. >> >> >> >> >> >> On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: >> >>> >> >>> servlet spec requirement is only for distributed systems AFAIK == not >> >>> required in most of instances. >> >>> tomee supports both and is aligned on tomcat for all tomee flavors and >> >>> is serialization-less in openejb flavors >> >>> >> >>> That said this is not a certification question but a usage question >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-03 10:59 GMT+01:00 Werner Keil : >> >>>> >> >>>> What about TomEE? >> >>>> After all it's Java EE 6 certified: >> >>>> >> >>>> >> >>>> http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html >> >>>> >> >>>> So as Mark mentioned briefly, there is a requirement by the Servlet >> >>>> spec, so >> >>>> I assume it is either always on or at least on by default (otherwise >> >>>> a >> >>>> TomEE >> >>>> "tweaked" like that would no longer be Java EE compliant;-) >> >>>> >> >>>> Tomcat itself was never certified. >> >>>> >> >>>> Werner >> >>>> >> >>>> >> >>>> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) >> >>>>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> >>>>> 3. Re: Clarify scopes and serialization (Mark Struberg) >> >>>>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) >> >>>>> 5. Re: Async events. We need ideas to improve CDI-499 >> >>>>> (Jozef Hartinger) >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------------------------------------------------------------------- >> >>>>> >> >>>>> >> >>>>> Message: 4 >> >>>>> Date: Mon, 2 Feb 2015 16:50:44 +0100 >> >>>>> From: Romain Manni-Bucau >> >>>>> Subject: Re: [cdi-dev] Clarify scopes and serialization >> >>>>> To: Mark Struberg >> >>>>> Cc: cdi-dev >> >>>>> Message-ID: >> >>>>> >> >>>>> >> >>>>> Content-Type: text/plain; charset=UTF-8 >> >>>>> >> >>>>> >> >>>>> in a standard tomcat yes but not in most of embedded ones...and >> >>>>> that's >> >>>>> not the point anyway >> >>>>> >> >>>>> >> >>>>> Romain Manni-Bucau >> >>>>> @rmannibucau >> >>>>> http://www.tomitribe.com >> >>>>> http://rmannibucau.wordpress.com >> >>>>> https://github.com/rmannibucau >> >>>>> >> >>>>> >> >>>>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : >> >>>>>> >> >>>>>> but you HAVE to manually switch it off. By _default_ the >> >>>>>> serialization >> >>>>>> is on... >> >>>>>> >> >>>>>> LieGrue, >> >>>>>> strub >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> @Mark: that's not true. 1) you can switch it off + I mainly spoke >> >>>>>>>> of >> >>>>>>> >> >>>>>>> embedded case where it is true in 80% of cases >> >>>>>>> >> >>>>>>> >> >>>>>>> Romain Manni-Bucau >> >>>>>>> @rmannibucau >> >>>>>>> http://www.tomitribe.com >> >>>>>>> http://rmannibucau.wordpress.com >> >>>>>>> https://github.com/rmannibucau >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : >> >>>>>>>> >> >>>>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes >> >>>>>>>> the >> >>>>>>> >> >>>>>>> session at shutdown! Even if you don't have a cluster set up. This >> >>>>>>> is >> >>>>>>> also >> >>>>>>> required by the Servlets spec... >> >>>>>>>> >> >>>>>>>> LieGrue, >> >>>>>>>> strub >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> _______________________________________________ >> >>>>> 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 51, Issue 4 >> >>>>> ************************************** >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 werner.keil at gmail.com Tue Feb 3 05:44:51 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 3 Feb 2015 11:44:51 +0100 Subject: [cdi-dev] Clarify scopes and serialization In-Reply-To: References: <54D0A022.1020104@redhat.com> Message-ID: Mark did, I'm sure he'll be able to help clarify that if you need his input;-) On Tue, Feb 3, 2015 at 11:30 AM, Romain Manni-Bucau wrote: > still dont get why you keep saying servlet spec assume serialization... > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-03 11:30 GMT+01:00 Werner Keil : > > That you'd have to ask the Servlet Spec Leads: > > https://jcp.org/en/jsr/detail?id=369 > > As of now, it seems Tomitribe has no EG Member there, but I'm sure you > could > > discuss anything with them if you feel it is a burden or makes no > sense;-) > > > > Werner > > > > > > On Tue, Feb 3, 2015 at 11:24 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> > > wrote: > >> > >> point is while serialization itself is not specified you have no more > >> guarantee with Serializable. ATM you can serialize your bean > >> passivationId and keep your bean instance in memory (in a map). You > >> didnt serialize anything excepted a string! > >> > >> So why forcing such a constraint if it is an implementation detail? > >> Serialization process is not explicit so then constraint doesnt > >> guarantee any portability > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-03 11:22 GMT+01:00 Werner Keil : > >> > Guess Jozef pretty much hit the point, I don't care about the sticker > or > >> > label you may put on your laptop or product, but a compatible behavior > >> > allowing users to deploy against as many available containers as > >> > possible > >> > with minimal or no changes at all;-) > >> > > >> > On Tue, Feb 3, 2015 at 11:17 AM, Jozef Hartinger > > >> > wrote: > >> >> > >> >> If we want applications to be portable across different > implementations > >> >> then the spec should require the least common multiple - that is > beans > >> >> that > >> >> belong to passivating scopes being serializable. TomEE/OWB is free to > >> >> have a > >> >> mode in which passivation requirements are not checked if the server > >> >> runs in > >> >> non-passivating mode. > >> >> > >> >> > >> >> On 02/03/2015 11:03 AM, Romain Manni-Bucau wrote: > >> >>> > >> >>> servlet spec requirement is only for distributed systems AFAIK == > not > >> >>> required in most of instances. > >> >>> tomee supports both and is aligned on tomcat for all tomee flavors > and > >> >>> is serialization-less in openejb flavors > >> >>> > >> >>> That said this is not a certification question but a usage question > >> >>> > >> >>> > >> >>> Romain Manni-Bucau > >> >>> @rmannibucau > >> >>> http://www.tomitribe.com > >> >>> http://rmannibucau.wordpress.com > >> >>> https://github.com/rmannibucau > >> >>> > >> >>> > >> >>> 2015-02-03 10:59 GMT+01:00 Werner Keil : > >> >>>> > >> >>>> What about TomEE? > >> >>>> After all it's Java EE 6 certified: > >> >>>> > >> >>>> > >> >>>> > http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html > >> >>>> > >> >>>> So as Mark mentioned briefly, there is a requirement by the Servlet > >> >>>> spec, so > >> >>>> I assume it is either always on or at least on by default > (otherwise > >> >>>> a > >> >>>> TomEE > >> >>>> "tweaked" like that would no longer be Java EE compliant;-) > >> >>>> > >> >>>> Tomcat itself was never certified. > >> >>>> > >> >>>> Werner > >> >>>> > >> >>>> > >> >>>> On Tue, Feb 3, 2015 at 9:39 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: Clarify scopes and serialization (Mark Struberg) > >> >>>>> 2. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >> >>>>> 3. Re: Clarify scopes and serialization (Mark Struberg) > >> >>>>> 4. Re: Clarify scopes and serialization (Romain Manni-Bucau) > >> >>>>> 5. Re: Async events. We need ideas to improve CDI-499 > >> >>>>> (Jozef Hartinger) > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > ---------------------------------------------------------------------- > >> >>>>> > >> >>>>> > >> >>>>> Message: 4 > >> >>>>> Date: Mon, 2 Feb 2015 16:50:44 +0100 > >> >>>>> From: Romain Manni-Bucau > >> >>>>> Subject: Re: [cdi-dev] Clarify scopes and serialization > >> >>>>> To: Mark Struberg > >> >>>>> Cc: cdi-dev > >> >>>>> Message-ID: > >> >>>>> > >> >>>>> 7MUGeq_bgdx0W_hPT-15-9ae_XdD3kab0P3vE4YHftKRg at mail.gmail.com> > >> >>>>> Content-Type: text/plain; charset=UTF-8 > >> >>>>> > >> >>>>> > >> >>>>> in a standard tomcat yes but not in most of embedded ones...and > >> >>>>> that's > >> >>>>> not the point anyway > >> >>>>> > >> >>>>> > >> >>>>> Romain Manni-Bucau > >> >>>>> @rmannibucau > >> >>>>> http://www.tomitribe.com > >> >>>>> http://rmannibucau.wordpress.com > >> >>>>> https://github.com/rmannibucau > >> >>>>> > >> >>>>> > >> >>>>> 2015-02-02 16:50 GMT+01:00 Mark Struberg : > >> >>>>>> > >> >>>>>> but you HAVE to manually switch it off. By _default_ the > >> >>>>>> serialization > >> >>>>>> is on... > >> >>>>>> > >> >>>>>> LieGrue, > >> >>>>>> strub > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>> On Monday, 2 February 2015, 16:42, Romain Manni-Bucau > >> >>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>> @Mark: that's not true. 1) you can switch it off + I mainly > spoke > >> >>>>>>>> of > >> >>>>>>> > >> >>>>>>> embedded case where it is true in 80% of cases > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Romain Manni-Bucau > >> >>>>>>> @rmannibucau > >> >>>>>>> http://www.tomitribe.com > >> >>>>>>> http://rmannibucau.wordpress.com > >> >>>>>>> https://github.com/rmannibucau > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 2015-02-02 16:38 GMT+01:00 Mark Struberg : > >> >>>>>>>> > >> >>>>>>>> Romain, that's not true. Tomcat by default ALWAYS serializes > >> >>>>>>>> the > >> >>>>>>> > >> >>>>>>> session at shutdown! Even if you don't have a cluster set up. > This > >> >>>>>>> is > >> >>>>>>> also > >> >>>>>>> required by the Servlets spec... > >> >>>>>>>> > >> >>>>>>>> LieGrue, > >> >>>>>>>> strub > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>> _______________________________________________ > >> >>>>> 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 51, Issue 4 > >> >>>>> ************************************** > >> >>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> 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/20150203/96a7c3ef/attachment-0001.html From issues at jboss.org Thu Feb 5 05:01:49 2015 From: issues at jboss.org (James Strachan (JIRA)) Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: James Strachan created CDI-504: ---------------------------------- Summary: have a standard CDI annotation like @ConfigProperty from deltapsike Key: CDI-504 URL: https://issues.jboss.org/browse/CDI-504 Project: CDI Specification Issues Issue Type: Feature Request Reporter: James Strachan Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. Delta Spike as a @ConfigProperty annotation which works very nicely http://deltaspike.apache.org/documentation/configuration.html you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 5 10:30:50 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 ] Martin Kouba commented on CDI-504: ---------------------------------- What's wrong with {{java.lang.System.getProperty()}} and {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration is IMO the resolution mechanism and the ability to extend the set of {{ConfigSource}} s. If you only need system properties and env variables a simple producer method and qualifier (or even a simple util method) would be sufficient. In other words I see no reason to standardize this. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 5 10:34:49 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 ] John Ament commented on CDI-504: -------------------------------- A separate config JSR has been proposed previously to address this. They want to see more options before trying to standardize it. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 5 10:39:49 2015 From: issues at jboss.org (James Strachan (JIRA)) Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan commented on CDI-504: ------------------------------------ @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert to a String with error handling.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 5 10:49:49 2015 From: issues at jboss.org (James Strachan (JIRA)) Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: ------------------------------------------------------------- @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). was (Author: jastrachan): @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert to a String with error handling.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Feb 5 10:50:49 2015 From: issues at jboss.org (James Strachan (JIRA)) Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: ------------------------------------------------------------- @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} int bar; @Inject Foo() { barText = System.getenv("FOO"); if (barText == null) { barText = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... bar = someConvertCode(barText); } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Note that in the second case, folks could use the constructor explicitly without being bound to environment variables too; much cleaner, more modular code. Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). was (Author: jastrachan): @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 6 05:02:49 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 ] Antoine Sabot-Durand commented on CDI-504: ------------------------------------------ James, I don't get what's the problem with using DeltaSpike config solution? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From werner.keil at gmail.com Fri Feb 6 05:22:35 2015 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 6 Feb 2015 11:22:35 +0100 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like Message-ID: James, I agree with Antoine as IMHO this would exceed the scope of core CDI a bit. There was a discussion by Anatole Tresch (also member of this EG) about creating a dedicated Configuration JSR (modeled among others also a lot after what DeltaSpike does) but so far JCP officials first and foremost Oracle saw either no need or no resources to do this. Apache Tamaya was a logical result. If that could become a blue-print or initial contribution of a future JSR, let's see, maybe for EE 9. It uses other Apache projects like DeltaSpike where applicable, but may also define such annotations and types of its own, so I suggest you also share your ideas on a Tamaya mailing list or JIRA: http://tamaya.incubator.apache.org/index.html On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (Martin Kouba (JIRA)) > 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (John Ament (JIRA)) > 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (James Strachan (JIRA)) > 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) > From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > James Strachan created CDI-504: > ---------------------------------- > > Summary: have a standard CDI annotation like @ConfigProperty > from deltapsike > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > > Docker and containerisation is the new hotness; in the docker world images > are static and the main way of injecting configuration is via environment > variables - so that the same image can be reused but configured at run time > with different configuration values. (Changing configuration files requires > either different images to be created or using custom volumes which is less > ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to provide > a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of the > CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should win > if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 2 > Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) > From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 > ] > > Martin Kouba commented on CDI-504: > ---------------------------------- > > What's wrong with {{java.lang.System.getProperty()}} and > {{java.lang.System.getenv()}}? I mean the main advantage of DS > Configuration is IMO the resolution mechanism and the ability to extend the > set of {{ConfigSource}} s. If you only need system properties and env > variables a simple producer method and qualifier (or even a simple util > method) would be sufficient. In other words I see no reason to standardize > this. > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 3 > Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) > From: "John Ament (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 > ] > > John Ament commented on CDI-504: > -------------------------------- > > A separate config JSR has been proposed previously to address this. They > want to see more options before trying to standardize it. > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 4 > Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) > From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > ] > > James Strachan commented on CDI-504: > ------------------------------------ > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert to a String with error handling.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 5 > Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) > From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > ] > > James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: > ------------------------------------------------------------- > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > was (Author: jastrachan): > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert to a String with error handling.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 6 > Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) > From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > ] > > James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: > ------------------------------------------------------------- > > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > int bar; > @Inject Foo() { > barText = System.getenv("FOO"); > if (barText == null) { > barText = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > bar = someConvertCode(barText); > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Note that in the second case, folks could use the constructor explicitly > without being bound to environment variables too; much cleaner, more > modular code. > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > was (Author: jastrachan): > @Resource is supported - injecting values from JNDI. I don't see why > injecting values (with a default value) from the environment isn't also > supported too. There's a Java API for JNDI too so folks could look stuff up > in JNDI by hand and do the type conversions - but we've injection for those > values. > > Its also much cleaner code and can easily deal generically with type > conversion to long/double/float/date etc. > > Compare: > {code} > @Inject Foo(int bar, ...) { > bar = System.getenv("FOO"); > if (bar == null) { > bar = "someDefault"; > } > // now convert the String to an int with nice error handling and > reporting.... > } > {code} > to just: > {code} > @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > } > {code} > > Also by using an annotation it means its very easy to generate > documentation and tooling. (e.g. using APT you can know what all the > environment variables are used by CDI; either to report on demand or to > generate user documentation). > > > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > Message: 7 > Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) > From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like @ConfigProperty from deltapsike > To: cdi-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 > ] > > Antoine Sabot-Durand commented on CDI-504: > ------------------------------------------ > > James, I don't get what's the problem with using DeltaSpike config > solution? > > > have a standard CDI annotation like @ConfigProperty from deltapsike > > ------------------------------------------------------------------- > > > > Key: CDI-504 > > URL: https://issues.jboss.org/browse/CDI-504 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Reporter: James Strachan > > > > Docker and containerisation is the new hotness; in the docker world > images are static and the main way of injecting configuration is via > environment variables - so that the same image can be reused but configured > at run time with different configuration values. (Changing configuration > files requires either different images to be created or using custom > volumes which is less ideal in a containerized world). > > So IMHO CDI should provide a simple, natural way to allow environment > variables (or system properties) to be easily injected via CDI. > > Delta Spike as a @ConfigProperty annotation which works very nicely > > http://deltaspike.apache.org/documentation/configuration.html > > you can specify a name, default value and use it on an @Inject to > provide a value from env vars, system properties or provide a default. > > Given how core and useful this is - it feels like it should be part of > the CDI specification; its one simple annotation. > > Currently deltaspike provides a way to configure different sources and > whatnot which is cool; I'd be happy if CDI just had a simpler annotation > which was only bound to env vars / system properties. > > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > There could be debate on whether env vars or system properties should > win if the same name is used for both; in a dockerized world I'd prefer env > vars to win but folks can always tinker with their run command to make sure > they pass in env vars as system properties to work around this I guess. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.11#6341) > > > ------------------------------ > > _______________________________________________ > 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 51, Issue 9 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/1ea297cc/attachment-0001.html From issues at jboss.org Fri Feb 6 06:21:49 2015 From: issues at jboss.org (Pete Muir (JIRA)) Date: Fri, 6 Feb 2015 06:21:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038290#comment-13038290 ] Pete Muir commented on CDI-504: ------------------------------- This seems like a pretty good idea to me. Environment variables are part of Java since the beginning, and so we are adding something based on a very well specified area. This would have a lot of utility in the docker/microservice/devops view of the world, for very little cost. The reason not to use DS is to be able to depend on this everywhere, with no library. The reason to not just do producers is to make this globally available. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 6 06:45:49 2015 From: issues at jboss.org (James Strachan (JIRA)) Date: Fri, 6 Feb 2015 06:45:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038292#comment-13038292 ] James Strachan commented on CDI-504: ------------------------------------ @Antoine yeah - there's nothing wrong with deltaspike - I just feel it'd be nice for folks to just depend on the standard CDI APIs and jars and for env vars to be supported in all CDI environments > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From arjan.tijms at gmail.com Fri Feb 6 07:23:14 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 6 Feb 2015 13:23:14 +0100 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like In-Reply-To: References: Message-ID: Hi, On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil wrote: > but so far JCP officials first and foremost > Oracle saw either no need or no resources to do this. I remember some other issues being on the table, like Java SE vs Java EE and "configuring the runtime" vs "injecting/providing values to the app". DeltaSpike Configuration is really great, but it's a value provider. It doesn't let you swap out or overlay deployment descriptors etc. Kind regards, Arjan Tijms > > Apache Tamaya was a logical result. If that could become a blue-print or > initial contribution of a future JSR, let's see, maybe for EE 9. It uses > other Apache projects like DeltaSpike where applicable, but may also define > such annotations and types of its own, so I suggest you also share your > ideas on a Tamaya mailing list or JIRA: > http://tamaya.incubator.apache.org/index.html > > On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (James Strachan (JIRA)) >> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) >> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (John Ament (JIRA)) >> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (James Strachan (JIRA)) >> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (James Strachan (JIRA)) >> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (James Strachan (JIRA)) >> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) >> From: "James Strachan (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> James Strachan created CDI-504: >> ---------------------------------- >> >> Summary: have a standard CDI annotation like @ConfigProperty >> from deltapsike >> Key: CDI-504 >> URL: https://issues.jboss.org/browse/CDI-504 >> Project: CDI Specification Issues >> Issue Type: Feature Request >> Reporter: James Strachan >> >> >> Docker and containerisation is the new hotness; in the docker world images >> are static and the main way of injecting configuration is via environment >> variables - so that the same image can be reused but configured at run time >> with different configuration values. (Changing configuration files requires >> either different images to be created or using custom volumes which is less >> ideal in a containerized world). >> >> So IMHO CDI should provide a simple, natural way to allow environment >> variables (or system properties) to be easily injected via CDI. >> >> Delta Spike as a @ConfigProperty annotation which works very nicely >> http://deltaspike.apache.org/documentation/configuration.html >> >> you can specify a name, default value and use it on an @Inject to provide >> a value from env vars, system properties or provide a default. >> >> Given how core and useful this is - it feels like it should be part of the >> CDI specification; its one simple annotation. >> >> Currently deltaspike provides a way to configure different sources and >> whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> which was only bound to env vars / system properties. >> >> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> >> There could be debate on whether env vars or system properties should win >> if the same name is used for both; in a dockerized world I'd prefer env vars >> to win but folks can always tinker with their run command to make sure they >> pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) >> From: "Martin Kouba (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 >> ] >> >> Martin Kouba commented on CDI-504: >> ---------------------------------- >> >> What's wrong with {{java.lang.System.getProperty()}} and >> {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration >> is IMO the resolution mechanism and the ability to extend the set of >> {{ConfigSource}} s. If you only need system properties and env variables a >> simple producer method and qualifier (or even a simple util method) would be >> sufficient. In other words I see no reason to standardize this. >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) >> From: "John Ament (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 >> ] >> >> John Ament commented on CDI-504: >> -------------------------------- >> >> A separate config JSR has been proposed previously to address this. They >> want to see more options before trying to standardize it. >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) >> From: "James Strachan (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >> ] >> >> James Strachan commented on CDI-504: >> ------------------------------------ >> >> @Resource is supported - injecting values from JNDI. I don't see why >> injecting values (with a default value) from the environment isn't also >> supported too. There's a Java API for JNDI too so folks could look stuff up >> in JNDI by hand and do the type conversions - but we've injection for those >> values. >> >> Its also much cleaner code and can easily deal generically with type >> conversion to long/double/float/date etc. >> >> Compare: >> {code} >> @Inject Foo(int bar, ...) { >> bar = System.getenv("FOO"); >> if (bar == null) { >> bar = "someDefault"; >> } >> // now convert to a String with error handling.... >> } >> {code} >> to just: >> {code} >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >> } >> {code} >> >> Also by using an annotation it means its very easy to generate >> documentation and tooling. (e.g. using APT you can know what all the >> environment variables are used by CDI; either to report on demand or to >> generate user documentation). >> >> >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 5 >> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) >> From: "James Strachan (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >> ] >> >> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: >> ------------------------------------------------------------- >> >> @Resource is supported - injecting values from JNDI. I don't see why >> injecting values (with a default value) from the environment isn't also >> supported too. There's a Java API for JNDI too so folks could look stuff up >> in JNDI by hand and do the type conversions - but we've injection for those >> values. >> >> Its also much cleaner code and can easily deal generically with type >> conversion to long/double/float/date etc. >> >> Compare: >> {code} >> @Inject Foo(int bar, ...) { >> bar = System.getenv("FOO"); >> if (bar == null) { >> bar = "someDefault"; >> } >> // now convert the String to an int with nice error handling and >> reporting.... >> } >> {code} >> to just: >> {code} >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >> } >> {code} >> >> Also by using an annotation it means its very easy to generate >> documentation and tooling. (e.g. using APT you can know what all the >> environment variables are used by CDI; either to report on demand or to >> generate user documentation). >> >> >> >> >> was (Author: jastrachan): >> @Resource is supported - injecting values from JNDI. I don't see why >> injecting values (with a default value) from the environment isn't also >> supported too. There's a Java API for JNDI too so folks could look stuff up >> in JNDI by hand and do the type conversions - but we've injection for those >> values. >> >> Its also much cleaner code and can easily deal generically with type >> conversion to long/double/float/date etc. >> >> Compare: >> {code} >> @Inject Foo(int bar, ...) { >> bar = System.getenv("FOO"); >> if (bar == null) { >> bar = "someDefault"; >> } >> // now convert to a String with error handling.... >> } >> {code} >> to just: >> {code} >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >> } >> {code} >> >> Also by using an annotation it means its very easy to generate >> documentation and tooling. (e.g. using APT you can know what all the >> environment variables are used by CDI; either to report on demand or to >> generate user documentation). >> >> >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 6 >> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) >> From: "James Strachan (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >> ] >> >> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: >> ------------------------------------------------------------- >> >> @Resource is supported - injecting values from JNDI. I don't see why >> injecting values (with a default value) from the environment isn't also >> supported too. There's a Java API for JNDI too so folks could look stuff up >> in JNDI by hand and do the type conversions - but we've injection for those >> values. >> >> Its also much cleaner code and can easily deal generically with type >> conversion to long/double/float/date etc. >> >> Compare: >> {code} >> int bar; >> @Inject Foo() { >> barText = System.getenv("FOO"); >> if (barText == null) { >> barText = "someDefault"; >> } >> // now convert the String to an int with nice error handling and >> reporting.... >> bar = someConvertCode(barText); >> } >> {code} >> to just: >> {code} >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >> } >> {code} >> >> Note that in the second case, folks could use the constructor explicitly >> without being bound to environment variables too; much cleaner, more modular >> code. >> >> Also by using an annotation it means its very easy to generate >> documentation and tooling. (e.g. using APT you can know what all the >> environment variables are used by CDI; either to report on demand or to >> generate user documentation). >> >> >> >> >> was (Author: jastrachan): >> @Resource is supported - injecting values from JNDI. I don't see why >> injecting values (with a default value) from the environment isn't also >> supported too. There's a Java API for JNDI too so folks could look stuff up >> in JNDI by hand and do the type conversions - but we've injection for those >> values. >> >> Its also much cleaner code and can easily deal generically with type >> conversion to long/double/float/date etc. >> >> Compare: >> {code} >> @Inject Foo(int bar, ...) { >> bar = System.getenv("FOO"); >> if (bar == null) { >> bar = "someDefault"; >> } >> // now convert the String to an int with nice error handling and >> reporting.... >> } >> {code} >> to just: >> {code} >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >> } >> {code} >> >> Also by using an annotation it means its very easy to generate >> documentation and tooling. (e.g. using APT you can know what all the >> environment variables are used by CDI; either to report on demand or to >> generate user documentation). >> >> >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> Message: 7 >> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) >> From: "Antoine Sabot-Durand (JIRA)" >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >> annotation like @ConfigProperty from deltapsike >> To: cdi-dev at lists.jboss.org >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> [ >> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 >> ] >> >> Antoine Sabot-Durand commented on CDI-504: >> ------------------------------------------ >> >> James, I don't get what's the problem with using DeltaSpike config >> solution? >> >> > have a standard CDI annotation like @ConfigProperty from deltapsike >> > ------------------------------------------------------------------- >> > >> > Key: CDI-504 >> > URL: https://issues.jboss.org/browse/CDI-504 >> > Project: CDI Specification Issues >> > Issue Type: Feature Request >> > Reporter: James Strachan >> > >> > Docker and containerisation is the new hotness; in the docker world >> > images are static and the main way of injecting configuration is via >> > environment variables - so that the same image can be reused but configured >> > at run time with different configuration values. (Changing configuration >> > files requires either different images to be created or using custom volumes >> > which is less ideal in a containerized world). >> > So IMHO CDI should provide a simple, natural way to allow environment >> > variables (or system properties) to be easily injected via CDI. >> > Delta Spike as a @ConfigProperty annotation which works very nicely >> > http://deltaspike.apache.org/documentation/configuration.html >> > you can specify a name, default value and use it on an @Inject to >> > provide a value from env vars, system properties or provide a default. >> > Given how core and useful this is - it feels like it should be part of >> > the CDI specification; its one simple annotation. >> > Currently deltaspike provides a way to configure different sources and >> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >> > which was only bound to env vars / system properties. >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >> > There could be debate on whether env vars or system properties should >> > win if the same name is used for both; in a dockerized world I'd prefer env >> > vars to win but folks can always tinker with their run command to make sure >> > they pass in env vars as system properties to work around this I guess. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.11#6341) >> >> >> ------------------------------ >> >> _______________________________________________ >> 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 51, Issue 9 >> ************************************** > > > > _______________________________________________ > 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 Fri Feb 6 07:33:06 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Feb 2015 05:33:06 -0700 (MST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like In-Reply-To: References: Message-ID: <1423225986023-5710923.post@n5.nabble.com> Werner, It would be better to answer Jira discussion on Jira to keep information on the ticket. Antoine -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Re-JBoss-JIRA-CDI-504-have-a-standard-CDI-annotation-like-tp5710919p5710923.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From werner.keil at gmail.com Fri Feb 6 07:33:36 2015 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 6 Feb 2015 13:33:36 +0100 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like Message-ID: If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-) On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms wrote: > Hi, > > On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil > wrote: > > but so far JCP officials first and foremost > > Oracle saw either no need or no resources to do this. > > I remember some other issues being on the table, like Java SE vs Java > EE and "configuring the runtime" vs "injecting/providing values to the > app". > > DeltaSpike Configuration is really great, but it's a value provider. > It doesn't let you swap out or overlay deployment descriptors etc. > > Kind regards, > Arjan Tijms > > > > > > > Apache Tamaya was a logical result. If that could become a blue-print or > > initial contribution of a future JSR, let's see, maybe for EE 9. It uses > > other Apache projects like DeltaSpike where applicable, but may also > define > > such annotations and types of its own, so I suggest you also share your > > ideas on a Tamaya mailing list or JIRA: > > http://tamaya.incubator.apache.org/index.html > > > > On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) > >> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (John Ament (JIRA)) > >> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) > >> From: "James Strachan (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> James Strachan created CDI-504: > >> ---------------------------------- > >> > >> Summary: have a standard CDI annotation like > @ConfigProperty > >> from deltapsike > >> Key: CDI-504 > >> URL: https://issues.jboss.org/browse/CDI-504 > >> Project: CDI Specification Issues > >> Issue Type: Feature Request > >> Reporter: James Strachan > >> > >> > >> Docker and containerisation is the new hotness; in the docker world > images > >> are static and the main way of injecting configuration is via > environment > >> variables - so that the same image can be reused but configured at run > time > >> with different configuration values. (Changing configuration files > requires > >> either different images to be created or using custom volumes which is > less > >> ideal in a containerized world). > >> > >> So IMHO CDI should provide a simple, natural way to allow environment > >> variables (or system properties) to be easily injected via CDI. > >> > >> Delta Spike as a @ConfigProperty annotation which works very nicely > >> http://deltaspike.apache.org/documentation/configuration.html > >> > >> you can specify a name, default value and use it on an @Inject to > provide > >> a value from env vars, system properties or provide a default. > >> > >> Given how core and useful this is - it feels like it should be part of > the > >> CDI specification; its one simple annotation. > >> > >> Currently deltaspike provides a way to configure different sources and > >> whatnot which is cool; I'd be happy if CDI just had a simpler annotation > >> which was only bound to env vars / system properties. > >> > >> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > >> There could be debate on whether env vars or system properties should > win > >> if the same name is used for both; in a dockerized world I'd prefer env > vars > >> to win but folks can always tinker with their run command to make sure > they > >> pass in env vars as system properties to work around this I guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) > >> From: "Martin Kouba (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 > >> ] > >> > >> Martin Kouba commented on CDI-504: > >> ---------------------------------- > >> > >> What's wrong with {{java.lang.System.getProperty()}} and > >> {{java.lang.System.getenv()}}? I mean the main advantage of DS > Configuration > >> is IMO the resolution mechanism and the ability to extend the set of > >> {{ConfigSource}} s. If you only need system properties and env > variables a > >> simple producer method and qualifier (or even a simple util method) > would be > >> sufficient. In other words I see no reason to standardize this. > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) > >> From: "John Ament (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 > >> ] > >> > >> John Ament commented on CDI-504: > >> -------------------------------- > >> > >> A separate config JSR has been proposed previously to address this. > They > >> want to see more options before trying to standardize it. > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 4 > >> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) > >> From: "James Strachan (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > >> ] > >> > >> James Strachan commented on CDI-504: > >> ------------------------------------ > >> > >> @Resource is supported - injecting values from JNDI. I don't see why > >> injecting values (with a default value) from the environment isn't also > >> supported too. There's a Java API for JNDI too so folks could look > stuff up > >> in JNDI by hand and do the type conversions - but we've injection for > those > >> values. > >> > >> Its also much cleaner code and can easily deal generically with type > >> conversion to long/double/float/date etc. > >> > >> Compare: > >> {code} > >> @Inject Foo(int bar, ...) { > >> bar = System.getenv("FOO"); > >> if (bar == null) { > >> bar = "someDefault"; > >> } > >> // now convert to a String with error handling.... > >> } > >> {code} > >> to just: > >> {code} > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >> } > >> {code} > >> > >> Also by using an annotation it means its very easy to generate > >> documentation and tooling. (e.g. using APT you can know what all the > >> environment variables are used by CDI; either to report on demand or to > >> generate user documentation). > >> > >> > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 5 > >> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) > >> From: "James Strachan (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > >> ] > >> > >> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: > >> ------------------------------------------------------------- > >> > >> @Resource is supported - injecting values from JNDI. I don't see why > >> injecting values (with a default value) from the environment isn't also > >> supported too. There's a Java API for JNDI too so folks could look > stuff up > >> in JNDI by hand and do the type conversions - but we've injection for > those > >> values. > >> > >> Its also much cleaner code and can easily deal generically with type > >> conversion to long/double/float/date etc. > >> > >> Compare: > >> {code} > >> @Inject Foo(int bar, ...) { > >> bar = System.getenv("FOO"); > >> if (bar == null) { > >> bar = "someDefault"; > >> } > >> // now convert the String to an int with nice error handling and > >> reporting.... > >> } > >> {code} > >> to just: > >> {code} > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >> } > >> {code} > >> > >> Also by using an annotation it means its very easy to generate > >> documentation and tooling. (e.g. using APT you can know what all the > >> environment variables are used by CDI; either to report on demand or to > >> generate user documentation). > >> > >> > >> > >> > >> was (Author: jastrachan): > >> @Resource is supported - injecting values from JNDI. I don't see why > >> injecting values (with a default value) from the environment isn't also > >> supported too. There's a Java API for JNDI too so folks could look > stuff up > >> in JNDI by hand and do the type conversions - but we've injection for > those > >> values. > >> > >> Its also much cleaner code and can easily deal generically with type > >> conversion to long/double/float/date etc. > >> > >> Compare: > >> {code} > >> @Inject Foo(int bar, ...) { > >> bar = System.getenv("FOO"); > >> if (bar == null) { > >> bar = "someDefault"; > >> } > >> // now convert to a String with error handling.... > >> } > >> {code} > >> to just: > >> {code} > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >> } > >> {code} > >> > >> Also by using an annotation it means its very easy to generate > >> documentation and tooling. (e.g. using APT you can know what all the > >> environment variables are used by CDI; either to report on demand or to > >> generate user documentation). > >> > >> > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 6 > >> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) > >> From: "James Strachan (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > >> ] > >> > >> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: > >> ------------------------------------------------------------- > >> > >> @Resource is supported - injecting values from JNDI. I don't see why > >> injecting values (with a default value) from the environment isn't also > >> supported too. There's a Java API for JNDI too so folks could look > stuff up > >> in JNDI by hand and do the type conversions - but we've injection for > those > >> values. > >> > >> Its also much cleaner code and can easily deal generically with type > >> conversion to long/double/float/date etc. > >> > >> Compare: > >> {code} > >> int bar; > >> @Inject Foo() { > >> barText = System.getenv("FOO"); > >> if (barText == null) { > >> barText = "someDefault"; > >> } > >> // now convert the String to an int with nice error handling and > >> reporting.... > >> bar = someConvertCode(barText); > >> } > >> {code} > >> to just: > >> {code} > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >> } > >> {code} > >> > >> Note that in the second case, folks could use the constructor explicitly > >> without being bound to environment variables too; much cleaner, more > modular > >> code. > >> > >> Also by using an annotation it means its very easy to generate > >> documentation and tooling. (e.g. using APT you can know what all the > >> environment variables are used by CDI; either to report on demand or to > >> generate user documentation). > >> > >> > >> > >> > >> was (Author: jastrachan): > >> @Resource is supported - injecting values from JNDI. I don't see why > >> injecting values (with a default value) from the environment isn't also > >> supported too. There's a Java API for JNDI too so folks could look > stuff up > >> in JNDI by hand and do the type conversions - but we've injection for > those > >> values. > >> > >> Its also much cleaner code and can easily deal generically with type > >> conversion to long/double/float/date etc. > >> > >> Compare: > >> {code} > >> @Inject Foo(int bar, ...) { > >> bar = System.getenv("FOO"); > >> if (bar == null) { > >> bar = "someDefault"; > >> } > >> // now convert the String to an int with nice error handling and > >> reporting.... > >> } > >> {code} > >> to just: > >> {code} > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >> } > >> {code} > >> > >> Also by using an annotation it means its very easy to generate > >> documentation and tooling. (e.g. using APT you can know what all the > >> environment variables are used by CDI; either to report on demand or to > >> generate user documentation). > >> > >> > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> Message: 7 > >> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) > >> From: "Antoine Sabot-Durand (JIRA)" > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >> annotation like @ConfigProperty from deltapsike > >> To: cdi-dev at lists.jboss.org > >> Message-ID: > >> > > >> Content-Type: text/plain; charset=UTF-8 > >> > >> > >> [ > >> > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 > >> ] > >> > >> Antoine Sabot-Durand commented on CDI-504: > >> ------------------------------------------ > >> > >> James, I don't get what's the problem with using DeltaSpike config > >> solution? > >> > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > >> > ------------------------------------------------------------------- > >> > > >> > Key: CDI-504 > >> > URL: https://issues.jboss.org/browse/CDI-504 > >> > Project: CDI Specification Issues > >> > Issue Type: Feature Request > >> > Reporter: James Strachan > >> > > >> > Docker and containerisation is the new hotness; in the docker world > >> > images are static and the main way of injecting configuration is via > >> > environment variables - so that the same image can be reused but > configured > >> > at run time with different configuration values. (Changing > configuration > >> > files requires either different images to be created or using custom > volumes > >> > which is less ideal in a containerized world). > >> > So IMHO CDI should provide a simple, natural way to allow environment > >> > variables (or system properties) to be easily injected via CDI. > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > >> > http://deltaspike.apache.org/documentation/configuration.html > >> > you can specify a name, default value and use it on an @Inject to > >> > provide a value from env vars, system properties or provide a default. > >> > Given how core and useful this is - it feels like it should be part of > >> > the CDI specification; its one simple annotation. > >> > Currently deltaspike provides a way to configure different sources and > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >> > which was only bound to env vars / system properties. > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >> > There could be debate on whether env vars or system properties should > >> > win if the same name is used for both; in a dockerized world I'd > prefer env > >> > vars to win but folks can always tinker with their run command to > make sure > >> > they pass in env vars as system properties to work around this I > guess. > >> > >> > >> > >> -- > >> This message was sent by Atlassian JIRA > >> (v6.3.11#6341) > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> 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 51, Issue 9 > >> ************************************** > > > > > > > > _______________________________________________ > > 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/20150206/bb2c4eaa/attachment-0001.html From werner.keil at gmail.com Fri Feb 6 07:36:10 2015 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 6 Feb 2015 13:36:10 +0100 Subject: [cdi-dev] cdi-dev Digest, Vol 51, Issue 12 In-Reply-To: References: Message-ID: How did it come here in the first place is there some automated mirror from the JIRA tickets?;-) I should have a JIRA user from Agorava, so I may use it there. On Fri, Feb 6, 2015 at 1:33 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. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation > like (Antoine Sabot-Durand) > 2. Re: [JBoss JIRA] (CDI-504) have a standard CDI annotation > like (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 6 Feb 2015 05:33:06 -0700 (MST) > From: Antoine Sabot-Durand > Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like > To: cdi-dev at lists.jboss.org > Message-ID: <1423225986023-5710923.post at n5.nabble.com> > Content-Type: text/plain; charset=us-ascii > > Werner, It would be better to answer Jira discussion on Jira to keep > information on the ticket. > > Antoine > > > > -- > View this message in context: > http://cdi-development-mailing-list.1064426.n5.nabble.com/Re-JBoss-JIRA-CDI-504-have-a-standard-CDI-annotation-like-tp5710919p5710923.html > Sent from the CDI Development mailing list mailing list archive at > Nabble.com. > > > ------------------------------ > > Message: 2 > Date: Fri, 6 Feb 2015 13:33:36 +0100 > From: Werner Keil > Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > annotation like > To: arjan tijms > Cc: cdi-dev > Message-ID: > < > CAAGawe3_v086e6LYG8mh6burZOm+P+FyS4XS2BJ-TrfA+ELvXQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > If DeltaSpike Configuration already covered everything there would have > been no need for Tamaya;-) > > On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms wrote: > > > Hi, > > > > On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil > > wrote: > > > but so far JCP officials first and foremost > > > Oracle saw either no need or no resources to do this. > > > > I remember some other issues being on the table, like Java SE vs Java > > EE and "configuring the runtime" vs "injecting/providing values to the > > app". > > > > DeltaSpike Configuration is really great, but it's a value provider. > > It doesn't let you swap out or overlay deployment descriptors etc. > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > Apache Tamaya was a logical result. If that could become a blue-print > or > > > initial contribution of a future JSR, let's see, maybe for EE 9. It > uses > > > other Apache projects like DeltaSpike where applicable, but may also > > define > > > such annotations and types of its own, so I suggest you also share your > > > ideas on a Tamaya mailing list or JIRA: > > > http://tamaya.incubator.apache.org/index.html > > > > > > On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > > >> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) > > >> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (John Ament (JIRA)) > > >> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > > >> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > > >> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (James Strachan (JIRA)) > > >> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > > >> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) > > >> > > >> > > >> ---------------------------------------------------------------------- > > >> > > >> Message: 1 > > >> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) > > >> From: "James Strachan (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> James Strachan created CDI-504: > > >> ---------------------------------- > > >> > > >> Summary: have a standard CDI annotation like > > @ConfigProperty > > >> from deltapsike > > >> Key: CDI-504 > > >> URL: https://issues.jboss.org/browse/CDI-504 > > >> Project: CDI Specification Issues > > >> Issue Type: Feature Request > > >> Reporter: James Strachan > > >> > > >> > > >> Docker and containerisation is the new hotness; in the docker world > > images > > >> are static and the main way of injecting configuration is via > > environment > > >> variables - so that the same image can be reused but configured at run > > time > > >> with different configuration values. (Changing configuration files > > requires > > >> either different images to be created or using custom volumes which is > > less > > >> ideal in a containerized world). > > >> > > >> So IMHO CDI should provide a simple, natural way to allow environment > > >> variables (or system properties) to be easily injected via CDI. > > >> > > >> Delta Spike as a @ConfigProperty annotation which works very nicely > > >> http://deltaspike.apache.org/documentation/configuration.html > > >> > > >> you can specify a name, default value and use it on an @Inject to > > provide > > >> a value from env vars, system properties or provide a default. > > >> > > >> Given how core and useful this is - it feels like it should be part of > > the > > >> CDI specification; its one simple annotation. > > >> > > >> Currently deltaspike provides a way to configure different sources and > > >> whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > > >> which was only bound to env vars / system properties. > > >> > > >> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > > >> There could be debate on whether env vars or system properties should > > win > > >> if the same name is used for both; in a dockerized world I'd prefer > env > > vars > > >> to win but folks can always tinker with their run command to make sure > > they > > >> pass in env vars as system properties to work around this I guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 2 > > >> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) > > >> From: "Martin Kouba (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 > > >> ] > > >> > > >> Martin Kouba commented on CDI-504: > > >> ---------------------------------- > > >> > > >> What's wrong with {{java.lang.System.getProperty()}} and > > >> {{java.lang.System.getenv()}}? I mean the main advantage of DS > > Configuration > > >> is IMO the resolution mechanism and the ability to extend the set of > > >> {{ConfigSource}} s. If you only need system properties and env > > variables a > > >> simple producer method and qualifier (or even a simple util method) > > would be > > >> sufficient. In other words I see no reason to standardize this. > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 3 > > >> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) > > >> From: "John Ament (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 > > >> ] > > >> > > >> John Ament commented on CDI-504: > > >> -------------------------------- > > >> > > >> A separate config JSR has been proposed previously to address this. > > They > > >> want to see more options before trying to standardize it. > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 4 > > >> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) > > >> From: "James Strachan (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > > >> ] > > >> > > >> James Strachan commented on CDI-504: > > >> ------------------------------------ > > >> > > >> @Resource is supported - injecting values from JNDI. I don't see why > > >> injecting values (with a default value) from the environment isn't > also > > >> supported too. There's a Java API for JNDI too so folks could look > > stuff up > > >> in JNDI by hand and do the type conversions - but we've injection for > > those > > >> values. > > >> > > >> Its also much cleaner code and can easily deal generically with type > > >> conversion to long/double/float/date etc. > > >> > > >> Compare: > > >> {code} > > >> @Inject Foo(int bar, ...) { > > >> bar = System.getenv("FOO"); > > >> if (bar == null) { > > >> bar = "someDefault"; > > >> } > > >> // now convert to a String with error handling.... > > >> } > > >> {code} > > >> to just: > > >> {code} > > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > > >> } > > >> {code} > > >> > > >> Also by using an annotation it means its very easy to generate > > >> documentation and tooling. (e.g. using APT you can know what all the > > >> environment variables are used by CDI; either to report on demand or > to > > >> generate user documentation). > > >> > > >> > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 5 > > >> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) > > >> From: "James Strachan (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > > >> ] > > >> > > >> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: > > >> ------------------------------------------------------------- > > >> > > >> @Resource is supported - injecting values from JNDI. I don't see why > > >> injecting values (with a default value) from the environment isn't > also > > >> supported too. There's a Java API for JNDI too so folks could look > > stuff up > > >> in JNDI by hand and do the type conversions - but we've injection for > > those > > >> values. > > >> > > >> Its also much cleaner code and can easily deal generically with type > > >> conversion to long/double/float/date etc. > > >> > > >> Compare: > > >> {code} > > >> @Inject Foo(int bar, ...) { > > >> bar = System.getenv("FOO"); > > >> if (bar == null) { > > >> bar = "someDefault"; > > >> } > > >> // now convert the String to an int with nice error handling and > > >> reporting.... > > >> } > > >> {code} > > >> to just: > > >> {code} > > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > > >> } > > >> {code} > > >> > > >> Also by using an annotation it means its very easy to generate > > >> documentation and tooling. (e.g. using APT you can know what all the > > >> environment variables are used by CDI; either to report on demand or > to > > >> generate user documentation). > > >> > > >> > > >> > > >> > > >> was (Author: jastrachan): > > >> @Resource is supported - injecting values from JNDI. I don't see why > > >> injecting values (with a default value) from the environment isn't > also > > >> supported too. There's a Java API for JNDI too so folks could look > > stuff up > > >> in JNDI by hand and do the type conversions - but we've injection for > > those > > >> values. > > >> > > >> Its also much cleaner code and can easily deal generically with type > > >> conversion to long/double/float/date etc. > > >> > > >> Compare: > > >> {code} > > >> @Inject Foo(int bar, ...) { > > >> bar = System.getenv("FOO"); > > >> if (bar == null) { > > >> bar = "someDefault"; > > >> } > > >> // now convert to a String with error handling.... > > >> } > > >> {code} > > >> to just: > > >> {code} > > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > > >> } > > >> {code} > > >> > > >> Also by using an annotation it means its very easy to generate > > >> documentation and tooling. (e.g. using APT you can know what all the > > >> environment variables are used by CDI; either to report on demand or > to > > >> generate user documentation). > > >> > > >> > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 6 > > >> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) > > >> From: "James Strachan (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 > > >> ] > > >> > > >> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: > > >> ------------------------------------------------------------- > > >> > > >> @Resource is supported - injecting values from JNDI. I don't see why > > >> injecting values (with a default value) from the environment isn't > also > > >> supported too. There's a Java API for JNDI too so folks could look > > stuff up > > >> in JNDI by hand and do the type conversions - but we've injection for > > those > > >> values. > > >> > > >> Its also much cleaner code and can easily deal generically with type > > >> conversion to long/double/float/date etc. > > >> > > >> Compare: > > >> {code} > > >> int bar; > > >> @Inject Foo() { > > >> barText = System.getenv("FOO"); > > >> if (barText == null) { > > >> barText = "someDefault"; > > >> } > > >> // now convert the String to an int with nice error handling and > > >> reporting.... > > >> bar = someConvertCode(barText); > > >> } > > >> {code} > > >> to just: > > >> {code} > > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > > >> } > > >> {code} > > >> > > >> Note that in the second case, folks could use the constructor > explicitly > > >> without being bound to environment variables too; much cleaner, more > > modular > > >> code. > > >> > > >> Also by using an annotation it means its very easy to generate > > >> documentation and tooling. (e.g. using APT you can know what all the > > >> environment variables are used by CDI; either to report on demand or > to > > >> generate user documentation). > > >> > > >> > > >> > > >> > > >> was (Author: jastrachan): > > >> @Resource is supported - injecting values from JNDI. I don't see why > > >> injecting values (with a default value) from the environment isn't > also > > >> supported too. There's a Java API for JNDI too so folks could look > > stuff up > > >> in JNDI by hand and do the type conversions - but we've injection for > > those > > >> values. > > >> > > >> Its also much cleaner code and can easily deal generically with type > > >> conversion to long/double/float/date etc. > > >> > > >> Compare: > > >> {code} > > >> @Inject Foo(int bar, ...) { > > >> bar = System.getenv("FOO"); > > >> if (bar == null) { > > >> bar = "someDefault"; > > >> } > > >> // now convert the String to an int with nice error handling and > > >> reporting.... > > >> } > > >> {code} > > >> to just: > > >> {code} > > >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > > >> } > > >> {code} > > >> > > >> Also by using an annotation it means its very easy to generate > > >> documentation and tooling. (e.g. using APT you can know what all the > > >> environment variables are used by CDI; either to report on demand or > to > > >> generate user documentation). > > >> > > >> > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 7 > > >> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) > > >> From: "Antoine Sabot-Durand (JIRA)" > > >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > > >> annotation like @ConfigProperty from deltapsike > > >> To: cdi-dev at lists.jboss.org > > >> Message-ID: > > >> > > > > > >> Content-Type: text/plain; charset=UTF-8 > > >> > > >> > > >> [ > > >> > > > https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 > > >> ] > > >> > > >> Antoine Sabot-Durand commented on CDI-504: > > >> ------------------------------------------ > > >> > > >> James, I don't get what's the problem with using DeltaSpike config > > >> solution? > > >> > > >> > have a standard CDI annotation like @ConfigProperty from deltapsike > > >> > ------------------------------------------------------------------- > > >> > > > >> > Key: CDI-504 > > >> > URL: https://issues.jboss.org/browse/CDI-504 > > >> > Project: CDI Specification Issues > > >> > Issue Type: Feature Request > > >> > Reporter: James Strachan > > >> > > > >> > Docker and containerisation is the new hotness; in the docker world > > >> > images are static and the main way of injecting configuration is via > > >> > environment variables - so that the same image can be reused but > > configured > > >> > at run time with different configuration values. (Changing > > configuration > > >> > files requires either different images to be created or using custom > > volumes > > >> > which is less ideal in a containerized world). > > >> > So IMHO CDI should provide a simple, natural way to allow > environment > > >> > variables (or system properties) to be easily injected via CDI. > > >> > Delta Spike as a @ConfigProperty annotation which works very nicely > > >> > http://deltaspike.apache.org/documentation/configuration.html > > >> > you can specify a name, default value and use it on an @Inject to > > >> > provide a value from env vars, system properties or provide a > default. > > >> > Given how core and useful this is - it feels like it should be part > of > > >> > the CDI specification; its one simple annotation. > > >> > Currently deltaspike provides a way to configure different sources > and > > >> > whatnot which is cool; I'd be happy if CDI just had a simpler > > annotation > > >> > which was only bound to env vars / system properties. > > >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > > >> > There could be debate on whether env vars or system properties > should > > >> > win if the same name is used for both; in a dockerized world I'd > > prefer env > > >> > vars to win but folks can always tinker with their run command to > > make sure > > >> > they pass in env vars as system properties to work around this I > > guess. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.11#6341) > > >> > > >> > > >> ------------------------------ > > >> > > >> _______________________________________________ > > >> 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 51, Issue 9 > > >> ************************************** > > > > > > > > > > > > _______________________________________________ > > > 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/20150206/bb2c4eaa/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 51, Issue 12 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/1e7423d5/attachment-0001.html From antoine at sabot-durand.net Fri Feb 6 08:06:23 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Feb 2015 14:06:23 +0100 Subject: [cdi-dev] New content on the site Message-ID: <15AE1542-AF47-40A4-91F6-323244356F9A@sabot-durand.net> Hi all, I?ve just added 2 new sections the website. - The first is the ecosystem page : http://www.cdi-spec.org/ecosystem/ it contains tools, framework and project based or using CDI. If you have other pointer or project, please feel free to tell me or do a Pull Request to the website repo : https://github.com/cdi-spec/cdi-spec.org . How to contribute on the site is in the readme.adoc file - The second is the integration of the Mailing Lsit mirror from Nabble Forum : http://www.cdi-spec.org/mailinglist/ It allows casual visitor to have easier view on our discussion without subscribing and give us a more convenient tool to browse and search our achive. You can use this interface to post to the ml, you?ll just have to create a Nabble account with the same email used to subscribe to the ML. Of course your feedback, remarks and questions are most welcome. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/9141dde3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/9141dde3/attachment.bin From rajmahendra at gmail.com Fri Feb 6 10:01:02 2015 From: rajmahendra at gmail.com (rajmahendra at gmail.com) Date: Fri, 6 Feb 2015 20:31:02 +0530 Subject: [cdi-dev] New content on the site In-Reply-To: <15AE1542-AF47-40A4-91F6-323244356F9A@sabot-durand.net> References: <15AE1542-AF47-40A4-91F6-323244356F9A@sabot-durand.net> Message-ID: +1 Very informative. On Fri, Feb 6, 2015 at 6:36 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > I?ve just added 2 new sections the website. > - The first is the ecosystem page : http://www.cdi-spec.org/ecosystem/ > it contains tools, framework and project based or using CDI. If you have > other pointer or project, please feel free to tell me or do a Pull Request > to the website repo : https://github.com/cdi-spec/cdi-spec.org. How to > contribute on the site is in the readme.adoc file > > - The second is the integration of the Mailing Lsit mirror from Nabble > Forum : http://www.cdi-spec.org/mailinglist/ > It allows casual visitor to have easier view on our discussion without > subscribing and give us a more convenient tool to browse and search our > achive. You can use this interface to post to the ml, you?ll just have to > create a Nabble account with the same email used to subscribe to the ML. > > Of course your feedback, remarks and questions are most welcome. > > 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. > -- Thank you and regards, Rajmahendra (*Raj*) Founder / Lead JUG Chennai/Hyderabad NetBeans Dream Team Member http://www.twitter.com/rajonjava ---------------------------------------------------------------------------------------------- "DREAM is not what you see in sleep; is the thing which does not let you sleep" - APJ Abdul Kalam Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step. - Lao Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/d585e862/attachment.html From issues at jboss.org Fri Feb 6 11:41:48 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Fri, 6 Feb 2015 11:41:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-505) Clarification on getInvokedBusinessInterfact() with conflicting throws clause In-Reply-To: References: Message-ID: Emily Jiang created CDI-505: ------------------------------- Summary: Clarification on getInvokedBusinessInterfact() with conflicting throws clause Key: CDI-505 URL: https://issues.jboss.org/browse/CDI-505 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.2.Final Environment: n/a Reporter: Emily Jiang Priority: Minor In the CDI 1.2 spec, it states: When a contextual instance of a session bean is obtained via the dependency injection service,the behavior of SessionContext.getInvokedBusinessInterface() is specific to the container implementation. Portable applications should not rely upon the value returned by this method. However, it needs to specify what should happen when an EJB has multiple interfaces with conflicting throws clauses for the same method. The preferred outcome would be that CDI mandates getInvokedBusinessInterface and conflicting throws clauses work as expected. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From thjanssen123 at gmail.com Fri Feb 6 13:59:09 2015 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Fri, 6 Feb 2015 19:59:09 +0100 Subject: [cdi-dev] New content on the site In-Reply-To: References: <15AE1542-AF47-40A4-91F6-323244356F9A@sabot-durand.net> Message-ID: Hi Antoine, I like it, especially the mailing list mirror. What do you think about adding an educational section. It could link to recorded talks, like your vJBUG session, and high quality tutorials and blog posts. Regards, Thorben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150206/eac16cdb/attachment.html From antoine at sabot-durand.net Sat Feb 7 07:07:00 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Sat, 7 Feb 2015 05:07:00 -0700 (MST) Subject: [cdi-dev] New content on the site In-Reply-To: References: <15AE1542-AF47-40A4-91F6-323244356F9A@sabot-durand.net> Message-ID: <1423310820260-5710930.post@n5.nabble.com> Yes Thorben the "Use CDI" section should have such content. All ideas and contribution are welcome for that as well ;). -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/New-content-on-the-site-tp5710926p5710930.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From issues at jboss.org Mon Feb 9 04:12:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Feb 2015 04:12:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038669#comment-13038669 ] Martin Kouba commented on CDI-504: ---------------------------------- [~jastrachan] [~pmuir] [~antoinesabot-durand] The out of box conversion and global availability convinced me :-). So there would be {{@EnvProperty}} and {{@SystemProperty}} and if a user wants more, there is the DS Configuration...? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:15:50 2015 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 9 Feb 2015 04:15:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038673#comment-13038673 ] Pete Muir commented on CDI-504: ------------------------------- I would prefer {{@EnvironmentProperty}} :-) This one is the important one, {{@System Property}} may be added for completeness. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:17:49 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 9 Feb 2015 04:17:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038675#comment-13038675 ] Romain Manni-Bucau commented on CDI-504: ---------------------------------------- +1 with few (minors notes): - @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO) - conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare. wdyt? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:17:49 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 9 Feb 2015 04:17:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038675#comment-13038675 ] Romain Manni-Bucau edited comment on CDI-504 at 2/9/15 4:17 AM: ---------------------------------------------------------------- +1 with few minors notes: - @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO) - conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare. wdyt? was (Author: rmannibucau): +1 with few (minors notes): - @Env and @SystemProperty maybe (instead of EnvProperty) to match JVM naming (@Property would be less meaningful IMO) - conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare. wdyt? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:25:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Feb 2015 04:25:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038676#comment-13038676 ] Martin Kouba commented on CDI-504: ---------------------------------- {quote} * @Env... {quote} +1 for omitting Property, it's an environment variable anyway. {quote} * conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare. {quote} +1, primitives + wrappers + java.lang.String might be enough. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:26:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Feb 2015 04:26:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038676#comment-13038676 ] Martin Kouba edited comment on CDI-504 at 2/9/15 4:26 AM: ---------------------------------------------------------- {quote} * @Env... {quote} +1 for omitting Property, it's an environment variable anyway. {quote} * conversion should be defined on a close set of types... {quote} +1, primitives + wrappers + java.lang.String might be enough. was (Author: mkouba): {quote} * @Env... {quote} +1 for omitting Property, it's an environment variable anyway. {quote} * conversion should be defined on a close set of types (primitives, wrapper + few java.lang/java.util + Collection + Map only) to ensure portability - not sure it is matre enough to support a good SPI ATM and if then it shouldnt be in config spec tamaya tries to prepare. {quote} +1, primitives + wrappers + java.lang.String might be enough. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:35:49 2015 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Mon, 9 Feb 2015 04:35:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038681#comment-13038681 ] Antonio Goncalves commented on CDI-504: --------------------------------------- Like [~meetoblivion] said, a Config JSR was planned for Java EE 8. It has been postponed (hopefully for EE 9). I don't think it's a good idea to add standard configuration capabilities to CDI. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 04:38:49 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 9 Feb 2015 04:38:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038683#comment-13038683 ] Romain Manni-Bucau commented on CDI-504: ---------------------------------------- I don't agree Antonio, config JSR can be justified only if it brings more than wrappers so it will not match all small apps we can write so a light default would still be nice. That said I agree it can (should?) be done outside CDI itself > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Mon Feb 9 04:51:12 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Feb 2015 09:51:12 +0000 (UTC) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like In-Reply-To: References: Message-ID: <1072543445.1122216.1423475472290.JavaMail.yahoo@mail.yahoo.com> >>DeltaSpike Configuration is really great, but it's a value provider. >>It doesn't let you swap out or overlay deployment descriptors etc. Just curious: What is the need for swapping out overlay XMLs? When do you do the replacement? At deploy time? At runtime? What about reconfiguration? Does it need a redeploy? etc. I had to live with it in WebLogic in a project. And to me it felt like it was pretty much broken as it did require a redeployment or at least a server reboot to change the configuration. That's simply a no-go. It also barely make sense in a time where most specs got completely rid of XML configs. > If DeltaSpike Configuration already covered everything > there would have been no need for Tamaya;-) The main goal is to get a JSR running. If we don't achieve this then there is really not that much benefit in Tamaya. But I am really hopeful that we DO get this done! LieGrue, strub On Friday, 6 February 2015, 13:34, Werner Keil wrote: > >If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-) > > >On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms wrote: > >Hi, >> >>On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil wrote: >>> but so far JCP officials first and foremost >>> Oracle saw either no need or no resources to do this. >> >>I remember some other issues being on the table, like Java SE vs Java >>EE and "configuring the runtime" vs "injecting/providing values to the >>app". >> >>DeltaSpike Configuration is really great, but it's a value provider. >>It doesn't let you swap out or overlay deployment descriptors etc. >> >>Kind regards, >>Arjan Tijms >> >> >> >> >>> >>> Apache Tamaya was a logical result. If that could become a blue-print or >>> initial contribution of a future JSR, let's see, maybe for EE 9. It uses >>> other Apache projects like DeltaSpike where applicable, but may also define >>> such annotations and types of its own, so I suggest you also share your >>> ideas on a Tamaya mailing list or JIRA: >>> http://tamaya.incubator.apache.org/index.html >>> >>> On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) >>>> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (John Ament (JIRA)) >>>> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) >>>> From: "James Strachan (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> James Strachan created CDI-504: >>>> ---------------------------------- >>>> >>>> Summary: have a standard CDI annotation like @ConfigProperty >>>> from deltapsike >>>> Key: CDI-504 >>>> URL: https://issues.jboss.org/browse/CDI-504 >>>> Project: CDI Specification Issues >>>> Issue Type: Feature Request >>>> Reporter: James Strachan >>>> >>>> >>>> Docker and containerisation is the new hotness; in the docker world images >>>> are static and the main way of injecting configuration is via environment >>>> variables - so that the same image can be reused but configured at run time >>>> with different configuration values. (Changing configuration files requires >>>> either different images to be created or using custom volumes which is less >>>> ideal in a containerized world). >>>> >>>> So IMHO CDI should provide a simple, natural way to allow environment >>>> variables (or system properties) to be easily injected via CDI. >>>> >>>> Delta Spike as a @ConfigProperty annotation which works very nicely >>>> http://deltaspike.apache.org/documentation/configuration.html >>>> >>>> you can specify a name, default value and use it on an @Inject to provide >>>> a value from env vars, system properties or provide a default. >>>> >>>> Given how core and useful this is - it feels like it should be part of the >>>> CDI specification; its one simple annotation. >>>> >>>> Currently deltaspike provides a way to configure different sources and >>>> whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> which was only bound to env vars / system properties. >>>> >>>> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> >>>> There could be debate on whether env vars or system properties should win >>>> if the same name is used for both; in a dockerized world I'd prefer env vars >>>> to win but folks can always tinker with their run command to make sure they >>>> pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) >>>> From: "Martin Kouba (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 >>>> ] >>>> >>>> Martin Kouba commented on CDI-504: >>>> ---------------------------------- >>>> >>>> What's wrong with {{java.lang.System.getProperty()}} and >>>> {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration >>>> is IMO the resolution mechanism and the ability to extend the set of >>>> {{ConfigSource}} s. If you only need system properties and env variables a >>>> simple producer method and qualifier (or even a simple util method) would be >>>> sufficient. In other words I see no reason to standardize this. >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) >>>> From: "John Ament (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 >>>> ] >>>> >>>> John Ament commented on CDI-504: >>>> -------------------------------- >>>> >>>> A separate config JSR has been proposed previously to address this. They >>>> want to see more options before trying to standardize it. >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 4 >>>> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) >>>> From: "James Strachan (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>> ] >>>> >>>> James Strachan commented on CDI-504: >>>> ------------------------------------ >>>> >>>> @Resource is supported - injecting values from JNDI. I don't see why >>>> injecting values (with a default value) from the environment isn't also >>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>> in JNDI by hand and do the type conversions - but we've injection for those >>>> values. >>>> >>>> Its also much cleaner code and can easily deal generically with type >>>> conversion to long/double/float/date etc. >>>> >>>> Compare: >>>> {code} >>>> @Inject Foo(int bar, ...) { >>>> bar = System.getenv("FOO"); >>>> if (bar == null) { >>>> bar = "someDefault"; >>>> } >>>> // now convert to a String with error handling.... >>>> } >>>> {code} >>>> to just: >>>> {code} >>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>> } >>>> {code} >>>> >>>> Also by using an annotation it means its very easy to generate >>>> documentation and tooling. (e.g. using APT you can know what all the >>>> environment variables are used by CDI; either to report on demand or to >>>> generate user documentation). >>>> >>>> >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 5 >>>> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) >>>> From: "James Strachan (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>> ] >>>> >>>> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: >>>> ------------------------------------------------------------- >>>> >>>> @Resource is supported - injecting values from JNDI. I don't see why >>>> injecting values (with a default value) from the environment isn't also >>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>> in JNDI by hand and do the type conversions - but we've injection for those >>>> values. >>>> >>>> Its also much cleaner code and can easily deal generically with type >>>> conversion to long/double/float/date etc. >>>> >>>> Compare: >>>> {code} >>>> @Inject Foo(int bar, ...) { >>>> bar = System.getenv("FOO"); >>>> if (bar == null) { >>>> bar = "someDefault"; >>>> } >>>> // now convert the String to an int with nice error handling and >>>> reporting.... >>>> } >>>> {code} >>>> to just: >>>> {code} >>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>> } >>>> {code} >>>> >>>> Also by using an annotation it means its very easy to generate >>>> documentation and tooling. (e.g. using APT you can know what all the >>>> environment variables are used by CDI; either to report on demand or to >>>> generate user documentation). >>>> >>>> >>>> >>>> >>>> was (Author: jastrachan): >>>> @Resource is supported - injecting values from JNDI. I don't see why >>>> injecting values (with a default value) from the environment isn't also >>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>> in JNDI by hand and do the type conversions - but we've injection for those >>>> values. >>>> >>>> Its also much cleaner code and can easily deal generically with type >>>> conversion to long/double/float/date etc. >>>> >>>> Compare: >>>> {code} >>>> @Inject Foo(int bar, ...) { >>>> bar = System.getenv("FOO"); >>>> if (bar == null) { >>>> bar = "someDefault"; >>>> } >>>> // now convert to a String with error handling.... >>>> } >>>> {code} >>>> to just: >>>> {code} >>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>> } >>>> {code} >>>> >>>> Also by using an annotation it means its very easy to generate >>>> documentation and tooling. (e.g. using APT you can know what all the >>>> environment variables are used by CDI; either to report on demand or to >>>> generate user documentation). >>>> >>>> >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 6 >>>> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) >>>> From: "James Strachan (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>> ] >>>> >>>> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: >>>> ------------------------------------------------------------- >>>> >>>> @Resource is supported - injecting values from JNDI. I don't see why >>>> injecting values (with a default value) from the environment isn't also >>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>> in JNDI by hand and do the type conversions - but we've injection for those >>>> values. >>>> >>>> Its also much cleaner code and can easily deal generically with type >>>> conversion to long/double/float/date etc. >>>> >>>> Compare: >>>> {code} >>>> int bar; >>>> @Inject Foo() { >>>> barText = System.getenv("FOO"); >>>> if (barText == null) { >>>> barText = "someDefault"; >>>> } >>>> // now convert the String to an int with nice error handling and >>>> reporting.... >>>> bar = someConvertCode(barText); >>>> } >>>> {code} >>>> to just: >>>> {code} >>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>> } >>>> {code} >>>> >>>> Note that in the second case, folks could use the constructor explicitly >>>> without being bound to environment variables too; much cleaner, more modular >>>> code. >>>> >>>> Also by using an annotation it means its very easy to generate >>>> documentation and tooling. (e.g. using APT you can know what all the >>>> environment variables are used by CDI; either to report on demand or to >>>> generate user documentation). >>>> >>>> >>>> >>>> >>>> was (Author: jastrachan): >>>> @Resource is supported - injecting values from JNDI. I don't see why >>>> injecting values (with a default value) from the environment isn't also >>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>> in JNDI by hand and do the type conversions - but we've injection for those >>>> values. >>>> >>>> Its also much cleaner code and can easily deal generically with type >>>> conversion to long/double/float/date etc. >>>> >>>> Compare: >>>> {code} >>>> @Inject Foo(int bar, ...) { >>>> bar = System.getenv("FOO"); >>>> if (bar == null) { >>>> bar = "someDefault"; >>>> } >>>> // now convert the String to an int with nice error handling and >>>> reporting.... >>>> } >>>> {code} >>>> to just: >>>> {code} >>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>> } >>>> {code} >>>> >>>> Also by using an annotation it means its very easy to generate >>>> documentation and tooling. (e.g. using APT you can know what all the >>>> environment variables are used by CDI; either to report on demand or to >>>> generate user documentation). >>>> >>>> >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 7 >>>> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) >>>> From: "Antoine Sabot-Durand (JIRA)" >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>> annotation like @ConfigProperty from deltapsike >>>> To: cdi-dev at lists.jboss.org >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> >>>> [ >>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 >>>> ] >>>> >>>> Antoine Sabot-Durand commented on CDI-504: >>>> ------------------------------------------ >>>> >>>> James, I don't get what's the problem with using DeltaSpike config >>>> solution? >>>> >>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>> > ------------------------------------------------------------------- >>>> > >>>> > Key: CDI-504 >>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>> > Project: CDI Specification Issues >>>> > Issue Type: Feature Request >>>> > Reporter: James Strachan >>>> > >>>> > Docker and containerisation is the new hotness; in the docker world >>>> > images are static and the main way of injecting configuration is via >>>> > environment variables - so that the same image can be reused but configured >>>> > at run time with different configuration values. (Changing configuration >>>> > files requires either different images to be created or using custom volumes >>>> > which is less ideal in a containerized world). >>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>> > variables (or system properties) to be easily injected via CDI. >>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>> > http://deltaspike.apache.org/documentation/configuration.html >>>> > you can specify a name, default value and use it on an @Inject to >>>> > provide a value from env vars, system properties or provide a default. >>>> > Given how core and useful this is - it feels like it should be part of >>>> > the CDI specification; its one simple annotation. >>>> > Currently deltaspike provides a way to configure different sources and >>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>> > which was only bound to env vars / system properties. >>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>> > There could be debate on whether env vars or system properties should >>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>> > vars to win but folks can always tinker with their run command to make sure >>>> > they pass in env vars as system properties to work around this I guess. >>>> >>>> >>>> >>>> -- >>>> This message was sent by Atlassian JIRA >>>> (v6.3.11#6341) >>>> >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> 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 51, Issue 9 >>>> ************************************** >>> >>> >>> >>> _______________________________________________ >>> 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 struberg at yahoo.de Mon Feb 9 05:12:22 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Feb 2015 10:12:22 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54D0892D.108@redhat.com> References: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> <54D0892D.108@redhat.com> Message-ID: <504649759.1128801.1423476742379.JavaMail.yahoo@mail.yahoo.com> Hi Jozef, here we go! 1.) accessing @RequestScoped beans in your Observer 2.) accessing @SessionScoped beans in your Observer 3.) accessing/relying on any transactional behaviour. This is really a boomer. Basically you break transactions that way. 4.) accessing @TransactionScoped beans in your Observer 5.) access/relying on any ThreadLocal in your Observer 6.) accessing attached entities in your Observers (they must only get accessed from a very single Thread according to the JPA spec) 7.) using an EntityManager in a parallel thread might give you unexpected results. There might be quite a few more. E.g. we need to specify that EJBs and other EE features need to work in such a new Thread, etc LieGrue, strub On Tuesday, 3 February 2015, 9:40, Jozef Hartinger wrote: > > >We should enumerate all the arguments supporting async flag on an observer. So far I have only seen one: > >- an observer accessing @RequestScoped state would no longer be able to do so since it would be run in a worker thread > >I am eager to hear more arguments as this single one may not be enough to justify the observer-async-flag design decision. > >Remember that introducing fireAsync() itself does not break any existing application because existing applications are using fire(). It's when an existing application / library is modified to use fireAsync() when the problem may occur. Such change should not be done blindly. As with any other change, an author should consider possible consequences of the change. Clearly documenting the fact that fireAsync() processing is done in a different thread with a different @RequestScoped state may be sufficient. > >Jozef > > >On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: > >Hi all, >> >> >> >> >>https://issues.jboss.org/browse/CDI-499 comes after a lot of discussion about async events. >> >> >>I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn?t please a lot of us. It?ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(. >> >> >>I?d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday. >> >> >>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. > >_______________________________________________ >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 Mon Feb 9 05:46:06 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 9 Feb 2015 11:46:06 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <504649759.1128801.1423476742379.JavaMail.yahoo@mail.yahoo.com> References: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> <54D0892D.108@redhat.com> <504649759.1128801.1423476742379.JavaMail.yahoo@mail.yahoo.com> Message-ID: Mark, During last meeting we didn?t say there wasn?t use case that would break existing observer, we said that since we keep the current fire() method there is backward compatibility. User trying to send fireAsync() and experiencing error with legacy observer will have to fall back to fire(). Antoine > Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : > > Hi Jozef, here we go! > > > 1.) accessing @RequestScoped beans in your Observer > > 2.) accessing @SessionScoped beans in your Observer > 3.) accessing/relying on any transactional behaviour. This is really a boomer. Basically you break transactions that way. > > 4.) accessing @TransactionScoped beans in your Observer > > 5.) access/relying on any ThreadLocal in your Observer > 6.) accessing attached entities in your Observers (they must only get accessed from a very single Thread according to the JPA spec) > 7.) using an EntityManager in a parallel thread might give you unexpected results. > > > There might be quite a few more. E.g. we need to specify that EJBs and other EE features need to work in such a new Thread, etc > > > LieGrue, > strub > > > On Tuesday, 3 February 2015, 9:40, Jozef Hartinger wrote: > > >> >> >> We should enumerate all the arguments supporting async flag on an observer. So far I have only seen one: >> >> - an observer accessing @RequestScoped state would no longer be able > to do so since it would be run in a worker thread >> >> I am eager to hear more arguments as this single one may not be > enough to justify the observer-async-flag design decision. >> >> Remember that introducing fireAsync() itself does not break any > existing application because existing applications are using fire(). > It's when an existing application / library is modified to use > fireAsync() when the problem may occur. Such change should not be > done blindly. As with any other change, an author should consider > possible consequences of the change. Clearly documenting the fact > that fireAsync() processing is done in a different thread with a > different @RequestScoped state may be sufficient. >> >> Jozef >> >> >> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >> >> Hi all, >>> >>> >>> >>> >>> https://issues.jboss.org/browse/CDI-499 comes after a lot of discussion about async events. >>> >>> >>> I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn?t please a lot of us. It?ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(. >>> >>> >>> I?d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday. >>> >>> >>> 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. >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150209/42b78d7a/attachment.bin From issues at jboss.org Mon Feb 9 05:54:50 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 9 Feb 2015 05:54:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038708#comment-13038708 ] Antoine Sabot-Durand commented on CDI-504: ------------------------------------------ I don't disagree with this idea but I have a few concerns or interrogations: # As [~pmuir] stated Java have been including API for dealing with env and system property for a long time. So from my point of view here (and correct me if I'm wrong), is that the biggest interest of this feature would be typesafe injection of these config values and thus conversion from string to requested type. I understand that we would only provide a very limited set of supported type out of the box. But if we don't provide SPI to allow third party to add their own converter it could become source of frustration and it won't be in the "all is SPIable" spirit of CDI. So we open the door to include a converter SPI in the spec. I'm worried about the out of scope and anti-diet aspect of the spec here... # In our discussion on Java SE boot in CDI-26 we have 2 {{init()}} method. One of them allows to boot the container with a parameter map {{init(Map params)}}. What about these parameter from the config point of view? Are they only there to configure specific aspect of the container or could they be used also for configuration purpose? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 05:58:49 2015 From: issues at jboss.org (Werner Keil (JIRA)) Date: Mon, 9 Feb 2015 05:58:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038710#comment-13038710 ] Werner Keil commented on CDI-504: --------------------------------- I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 9 05:59:49 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 9 Feb 2015 05:59:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038711#comment-13038711 ] Romain Manni-Bucau commented on CDI-504: ---------------------------------------- about 2 I think we should ensure this feature works for EE case - which is still the most common - so we shouldnt rely on these parameters. That said if they are here we should be able to use them as well so maybe let call SystemProperty just Property as a unified accessor. about : point about not providing a spi is to avoid to do a quarter of the work only and break in 1 or 2 versions of EE spec. If there is for EE 9 a config spec then this would integrate smoothly with the spi you speak about - added for EE 9/CDI "2+1". if we add it now then we'll conflict (pretty sure) > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Mon Feb 9 06:00:07 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Feb 2015 11:00:07 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: Message-ID: <2145261667.1123409.1423479607446.JavaMail.yahoo@mail.yahoo.com> But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... That will leave us half-broken as it totally defeats the usage of this cool feature... LieGrue, strub > On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: > > Mark, > > > During last meeting we didn?t say there wasn?t use case that would break > existing observer, we said that since we keep the current fire() method there is > backward compatibility. User trying to send fireAsync() and experiencing error > with legacy observer will have to fall back to fire(). > > Antoine > > > >> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >> >> Hi Jozef, here we go! >> >> >> 1.) accessing @RequestScoped beans in your Observer >> >> 2.) accessing @SessionScoped beans in your Observer >> 3.) accessing/relying on any transactional behaviour. This is really a > boomer. Basically you break transactions that way. >> >> 4.) accessing @TransactionScoped beans in your Observer >> >> 5.) access/relying on any ThreadLocal in your Observer >> 6.) accessing attached entities in your Observers (they must only get > accessed from a very single Thread according to the JPA spec) >> 7.) using an EntityManager in a parallel thread might give you unexpected > results. >> >> >> There might be quite a few more. E.g. we need to specify that EJBs and > other EE features need to work in such a new Thread, etc >> >> >> LieGrue, >> strub >> >> >> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger > wrote: >> >> >>> >>> >>> We should enumerate all the arguments supporting async flag on an > observer. So far I have only seen one: >>> >>> - an observer accessing @RequestScoped state would no longer be able >> to do so since it would be run in a worker thread >>> >>> I am eager to hear more arguments as this single one may not be >> enough to justify the observer-async-flag design decision. >>> >>> Remember that introducing fireAsync() itself does not break any >> existing application because existing applications are using fire(). >> It's when an existing application / library is modified to use >> fireAsync() when the problem may occur. Such change should not be >> done blindly. As with any other change, an author should consider >> possible consequences of the change. Clearly documenting the fact >> that fireAsync() processing is done in a different thread with a >> different @RequestScoped state may be sufficient. >>> >>> Jozef >>> >>> >>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>> >>> Hi all, >>>> >>>> >>>> >>>> >>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of > discussion about async events. >>>> >>>> >>>> I think the solution exposed here is quite satisfying, yet the idea > to need to activate async behaviour on the observer side doesn?t please a lot of > us. It?ll be confusing for users to have to activate async from the firing end > and consuming end to see it work :-(. >>>> >>>> >>>> I?d like to see alternative proposal to have this new feature as > user friendly as possible and keep the retro-compatibility aspect. We should > find a better solution on our next meeting on wednesday. >>>> >>>> >>>> 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. >>> >>> _______________________________________________ >>> 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 Mon Feb 9 06:02:49 2015 From: issues at jboss.org (Werner Keil (JIRA)) Date: Mon, 9 Feb 2015 06:02:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038710#comment-13038710 ] Werner Keil edited comment on CDI-504 at 2/9/15 6:01 AM: --------------------------------------------------------- I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR. See {{javax.decorator}} to make sense also for SE/desktop if CDI really defined such annotations they should be outside the {{javax.enterprise}} namespace at the very least. was (Author: wernerkeil): I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From arjan.tijms at gmail.com Mon Feb 9 08:08:47 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 9 Feb 2015 14:08:47 +0100 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like In-Reply-To: <1072543445.1122216.1423475472290.JavaMail.yahoo@mail.yahoo.com> References: <1072543445.1122216.1423475472290.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, On Mon, Feb 9, 2015 at 10:51 AM, Mark Struberg wrote: > Just curious: What is the need for swapping out overlay XMLs? There are many usecases, but one of them it having an extra Servlet in a few stages (say dev and beta) that gives tools special access to the application, or a dev filter that provides some extra options for development. Yet another case is swapping out the data-source element in say application.xml with different versions for each stage. > When do you do the replacement? At deploy time? At runtime? Most deployment descriptors are processed at deploy time, so when starting up the application. You specify say a -D parameter when starting up your server that specifies the stage of your server. The runtime then chooses an overlay (e.g. extra XML fragment) based on the value of the stage. >What about reconfiguration? Does it need a redeploy? The simplest case typically needs a redeploy indeed. Taking the example with the Servlets; the Servlet API only lets you add and remove Servlets and Filters during startup of the application. > etc. I had to live with it in WebLogic in a project. And to me it felt like it was pretty much broken as it did require a redeployment or at least a server reboot to change the configuration. That's simply a no-go. It might have been a no-go for your particular use case, but it's not in general. It's extremely rare that you need to change the stage of a running server. Frankly, in well over 10 years of designing, coding and operating Java EE systems of various sizes, I don't think I've ever encountered this. > It also barely make sense in a time where most specs got completely rid of XML configs. Wishful thinking if you'd ask me. While we surely go to more defaults and not *requiring* any upfront XML config if the user is satisfied with those defaults, Java EE is still firmly rooted in XML config. Quite a lot of configuration scenarios are contextual and not naturally expressibly in key/value pairs. I can speak for the JSF EG, and at least in JSF there is no moving to anything other than XML config (we have in fact discussed this). I'm not aware of anything in the Servlet EG either. Things like a Filter definition with their nested init params or security constraints etc are just not that naturally expressed as key/value pairs. JSON perhaps, but not key/value. I strongly believe there are two main aspects of configuration that should not be confused: 1. Configuring the container 2. Configuring the application Where configuring is a matter of: 1. Overlaying XML fragments (in practice mostly a relatively simply matter of choosing which fragment to include or not) 2. Providing EL or EL-like placeholders in XML and annotations 3. Providing key/values (and injecting them info the application) Both the container itself and the application can theoretically take advantage of any of these options, but it practice it seems the container configuration leans more towards 1, while the application leans more towards 3. I felt that the Java EE configuration JSR, now Tamaya, largely focussed on providing key/values and a means of injecting them into the application, and didn't think at all about deployment descriptors and placeholders in them. Kind regards, Arjan Tijms > > > >> If DeltaSpike Configuration already covered everything > >> there would have been no need for Tamaya;-) > > The main goal is to get a JSR running. If we don't achieve this then there is really not that much benefit in Tamaya. But I am really hopeful that we DO get this done! > > > > LieGrue, > strub > > > > On Friday, 6 February 2015, 13:34, Werner Keil wrote: >> >>If DeltaSpike Configuration already covered everything there would have been no need for Tamaya;-) >> >> >>On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms wrote: >> >>Hi, >>> >>>On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil wrote: >>>> but so far JCP officials first and foremost >>>> Oracle saw either no need or no resources to do this. >>> >>>I remember some other issues being on the table, like Java SE vs Java >>>EE and "configuring the runtime" vs "injecting/providing values to the >>>app". >>> >>>DeltaSpike Configuration is really great, but it's a value provider. >>>It doesn't let you swap out or overlay deployment descriptors etc. >>> >>>Kind regards, >>>Arjan Tijms >>> >>> >>> >>> >>>> >>>> Apache Tamaya was a logical result. If that could become a blue-print or >>>> initial contribution of a future JSR, let's see, maybe for EE 9. It uses >>>> other Apache projects like DeltaSpike where applicable, but may also define >>>> such annotations and types of its own, so I suggest you also share your >>>> ideas on a Tamaya mailing list or JIRA: >>>> http://tamaya.incubator.apache.org/index.html >>>> >>>> On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>>> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) >>>>> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (John Ament (JIRA)) >>>>> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>>> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>>> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) >>>>> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like >>>>> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Message: 1 >>>>> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) >>>>> From: "James Strachan (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> James Strachan created CDI-504: >>>>> ---------------------------------- >>>>> >>>>> Summary: have a standard CDI annotation like @ConfigProperty >>>>> from deltapsike >>>>> Key: CDI-504 >>>>> URL: https://issues.jboss.org/browse/CDI-504 >>>>> Project: CDI Specification Issues >>>>> Issue Type: Feature Request >>>>> Reporter: James Strachan >>>>> >>>>> >>>>> Docker and containerisation is the new hotness; in the docker world images >>>>> are static and the main way of injecting configuration is via environment >>>>> variables - so that the same image can be reused but configured at run time >>>>> with different configuration values. (Changing configuration files requires >>>>> either different images to be created or using custom volumes which is less >>>>> ideal in a containerized world). >>>>> >>>>> So IMHO CDI should provide a simple, natural way to allow environment >>>>> variables (or system properties) to be easily injected via CDI. >>>>> >>>>> Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> http://deltaspike.apache.org/documentation/configuration.html >>>>> >>>>> you can specify a name, default value and use it on an @Inject to provide >>>>> a value from env vars, system properties or provide a default. >>>>> >>>>> Given how core and useful this is - it feels like it should be part of the >>>>> CDI specification; its one simple annotation. >>>>> >>>>> Currently deltaspike provides a way to configure different sources and >>>>> whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> which was only bound to env vars / system properties. >>>>> >>>>> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> >>>>> There could be debate on whether env vars or system properties should win >>>>> if the same name is used for both; in a dockerized world I'd prefer env vars >>>>> to win but folks can always tinker with their run command to make sure they >>>>> pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 2 >>>>> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) >>>>> From: "Martin Kouba (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 >>>>> ] >>>>> >>>>> Martin Kouba commented on CDI-504: >>>>> ---------------------------------- >>>>> >>>>> What's wrong with {{java.lang.System.getProperty()}} and >>>>> {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration >>>>> is IMO the resolution mechanism and the ability to extend the set of >>>>> {{ConfigSource}} s. If you only need system properties and env variables a >>>>> simple producer method and qualifier (or even a simple util method) would be >>>>> sufficient. In other words I see no reason to standardize this. >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 3 >>>>> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) >>>>> From: "John Ament (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 >>>>> ] >>>>> >>>>> John Ament commented on CDI-504: >>>>> -------------------------------- >>>>> >>>>> A separate config JSR has been proposed previously to address this. They >>>>> want to see more options before trying to standardize it. >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 4 >>>>> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) >>>>> From: "James Strachan (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>>> ] >>>>> >>>>> James Strachan commented on CDI-504: >>>>> ------------------------------------ >>>>> >>>>> @Resource is supported - injecting values from JNDI. I don't see why >>>>> injecting values (with a default value) from the environment isn't also >>>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>>> in JNDI by hand and do the type conversions - but we've injection for those >>>>> values. >>>>> >>>>> Its also much cleaner code and can easily deal generically with type >>>>> conversion to long/double/float/date etc. >>>>> >>>>> Compare: >>>>> {code} >>>>> @Inject Foo(int bar, ...) { >>>>> bar = System.getenv("FOO"); >>>>> if (bar == null) { >>>>> bar = "someDefault"; >>>>> } >>>>> // now convert to a String with error handling.... >>>>> } >>>>> {code} >>>>> to just: >>>>> {code} >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>>> } >>>>> {code} >>>>> >>>>> Also by using an annotation it means its very easy to generate >>>>> documentation and tooling. (e.g. using APT you can know what all the >>>>> environment variables are used by CDI; either to report on demand or to >>>>> generate user documentation). >>>>> >>>>> >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 5 >>>>> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) >>>>> From: "James Strachan (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>>> ] >>>>> >>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: >>>>> ------------------------------------------------------------- >>>>> >>>>> @Resource is supported - injecting values from JNDI. I don't see why >>>>> injecting values (with a default value) from the environment isn't also >>>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>>> in JNDI by hand and do the type conversions - but we've injection for those >>>>> values. >>>>> >>>>> Its also much cleaner code and can easily deal generically with type >>>>> conversion to long/double/float/date etc. >>>>> >>>>> Compare: >>>>> {code} >>>>> @Inject Foo(int bar, ...) { >>>>> bar = System.getenv("FOO"); >>>>> if (bar == null) { >>>>> bar = "someDefault"; >>>>> } >>>>> // now convert the String to an int with nice error handling and >>>>> reporting.... >>>>> } >>>>> {code} >>>>> to just: >>>>> {code} >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>>> } >>>>> {code} >>>>> >>>>> Also by using an annotation it means its very easy to generate >>>>> documentation and tooling. (e.g. using APT you can know what all the >>>>> environment variables are used by CDI; either to report on demand or to >>>>> generate user documentation). >>>>> >>>>> >>>>> >>>>> >>>>> was (Author: jastrachan): >>>>> @Resource is supported - injecting values from JNDI. I don't see why >>>>> injecting values (with a default value) from the environment isn't also >>>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>>> in JNDI by hand and do the type conversions - but we've injection for those >>>>> values. >>>>> >>>>> Its also much cleaner code and can easily deal generically with type >>>>> conversion to long/double/float/date etc. >>>>> >>>>> Compare: >>>>> {code} >>>>> @Inject Foo(int bar, ...) { >>>>> bar = System.getenv("FOO"); >>>>> if (bar == null) { >>>>> bar = "someDefault"; >>>>> } >>>>> // now convert to a String with error handling.... >>>>> } >>>>> {code} >>>>> to just: >>>>> {code} >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>>> } >>>>> {code} >>>>> >>>>> Also by using an annotation it means its very easy to generate >>>>> documentation and tooling. (e.g. using APT you can know what all the >>>>> environment variables are used by CDI; either to report on demand or to >>>>> generate user documentation). >>>>> >>>>> >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 6 >>>>> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) >>>>> From: "James Strachan (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 >>>>> ] >>>>> >>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: >>>>> ------------------------------------------------------------- >>>>> >>>>> @Resource is supported - injecting values from JNDI. I don't see why >>>>> injecting values (with a default value) from the environment isn't also >>>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>>> in JNDI by hand and do the type conversions - but we've injection for those >>>>> values. >>>>> >>>>> Its also much cleaner code and can easily deal generically with type >>>>> conversion to long/double/float/date etc. >>>>> >>>>> Compare: >>>>> {code} >>>>> int bar; >>>>> @Inject Foo() { >>>>> barText = System.getenv("FOO"); >>>>> if (barText == null) { >>>>> barText = "someDefault"; >>>>> } >>>>> // now convert the String to an int with nice error handling and >>>>> reporting.... >>>>> bar = someConvertCode(barText); >>>>> } >>>>> {code} >>>>> to just: >>>>> {code} >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>>> } >>>>> {code} >>>>> >>>>> Note that in the second case, folks could use the constructor explicitly >>>>> without being bound to environment variables too; much cleaner, more modular >>>>> code. >>>>> >>>>> Also by using an annotation it means its very easy to generate >>>>> documentation and tooling. (e.g. using APT you can know what all the >>>>> environment variables are used by CDI; either to report on demand or to >>>>> generate user documentation). >>>>> >>>>> >>>>> >>>>> >>>>> was (Author: jastrachan): >>>>> @Resource is supported - injecting values from JNDI. I don't see why >>>>> injecting values (with a default value) from the environment isn't also >>>>> supported too. There's a Java API for JNDI too so folks could look stuff up >>>>> in JNDI by hand and do the type conversions - but we've injection for those >>>>> values. >>>>> >>>>> Its also much cleaner code and can easily deal generically with type >>>>> conversion to long/double/float/date etc. >>>>> >>>>> Compare: >>>>> {code} >>>>> @Inject Foo(int bar, ...) { >>>>> bar = System.getenv("FOO"); >>>>> if (bar == null) { >>>>> bar = "someDefault"; >>>>> } >>>>> // now convert the String to an int with nice error handling and >>>>> reporting.... >>>>> } >>>>> {code} >>>>> to just: >>>>> {code} >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { >>>>> } >>>>> {code} >>>>> >>>>> Also by using an annotation it means its very easy to generate >>>>> documentation and tooling. (e.g. using APT you can know what all the >>>>> environment variables are used by CDI; either to report on demand or to >>>>> generate user documentation). >>>>> >>>>> >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 7 >>>>> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) >>>>> From: "Antoine Sabot-Durand (JIRA)" >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI >>>>> annotation like @ConfigProperty from deltapsike >>>>> To: cdi-dev at lists.jboss.org >>>>> Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> >>>>> [ >>>>> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 >>>>> ] >>>>> >>>>> Antoine Sabot-Durand commented on CDI-504: >>>>> ------------------------------------------ >>>>> >>>>> James, I don't get what's the problem with using DeltaSpike config >>>>> solution? >>>>> >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike >>>>> > ------------------------------------------------------------------- >>>>> > >>>>> > Key: CDI-504 >>>>> > URL: https://issues.jboss.org/browse/CDI-504 >>>>> > Project: CDI Specification Issues >>>>> > Issue Type: Feature Request >>>>> > Reporter: James Strachan >>>>> > >>>>> > Docker and containerisation is the new hotness; in the docker world >>>>> > images are static and the main way of injecting configuration is via >>>>> > environment variables - so that the same image can be reused but configured >>>>> > at run time with different configuration values. (Changing configuration >>>>> > files requires either different images to be created or using custom volumes >>>>> > which is less ideal in a containerized world). >>>>> > So IMHO CDI should provide a simple, natural way to allow environment >>>>> > variables (or system properties) to be easily injected via CDI. >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely >>>>> > http://deltaspike.apache.org/documentation/configuration.html >>>>> > you can specify a name, default value and use it on an @Inject to >>>>> > provide a value from env vars, system properties or provide a default. >>>>> > Given how core and useful this is - it feels like it should be part of >>>>> > the CDI specification; its one simple annotation. >>>>> > Currently deltaspike provides a way to configure different sources and >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler annotation >>>>> > which was only bound to env vars / system properties. >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") >>>>> > There could be debate on whether env vars or system properties should >>>>> > win if the same name is used for both; in a dockerized world I'd prefer env >>>>> > vars to win but folks can always tinker with their run command to make sure >>>>> > they pass in env vars as system properties to work around this I guess. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message was sent by Atlassian JIRA >>>>> (v6.3.11#6341) >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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 51, Issue 9 >>>>> ************************************** >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Feb 9 08:16:50 2015 From: issues at jboss.org (Arjan t (JIRA)) Date: Mon, 9 Feb 2015 08:16:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038763#comment-13038763 ] Arjan t commented on CDI-504: ----------------------------- {quote}So we open the door to include a converter SPI in the spec. I'm worried about the out of scope and anti-diet aspect of the spec here...{quote} Maybe it's [high time to standardize Java EE converters?|http://arjan-tijms.omnifaces.org/2014/08/high-time-to-standardize-java-ee.html] ;) Not particularly looking forward to add CDI to the list I jotted down above. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From john.d.ament at gmail.com Mon Feb 9 08:18:49 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 09 Feb 2015 13:18:49 +0000 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like References: <1072543445.1122216.1423475472290.JavaMail.yahoo@mail.yahoo.com> Message-ID: I think everything you're describing are proposed pieces of the original config JSR. CDI shouldn't have any business in doing things like allowing the servlet spec to conditionally register a servlet. John On Mon Feb 09 2015 at 8:09:04 AM arjan tijms wrote: > Hi, > > On Mon, Feb 9, 2015 at 10:51 AM, Mark Struberg wrote: > > Just curious: What is the need for swapping out overlay XMLs? > > There are many usecases, but one of them it having an extra Servlet in > a few stages (say dev and beta) that gives tools special access to the > application, or a dev filter that provides some extra options for > development. > > Yet another case is swapping out the data-source element in say > application.xml with different versions for each stage. > > > When do you do the replacement? At deploy time? At runtime? > > Most deployment descriptors are processed at deploy time, so when > starting up the application. You specify say a -D parameter when > starting up your server that specifies the stage of your server. The > runtime then chooses an overlay (e.g. extra XML fragment) based on the > value of the stage. > > >What about reconfiguration? Does it need a redeploy? > > The simplest case typically needs a redeploy indeed. Taking the > example with the Servlets; the Servlet API only lets you add and > remove Servlets and Filters during startup of the application. > > > etc. I had to live with it in WebLogic in a project. And to me it felt > like it was pretty much broken as it did require a redeployment or at least > a server reboot to change the configuration. That's simply a no-go. > > It might have been a no-go for your particular use case, but it's not > in general. It's extremely rare that you need to change the stage of a > running server. Frankly, in well over 10 years of designing, coding > and operating Java EE systems of various sizes, I don't think I've > ever encountered this. > > > It also barely make sense in a time where most specs got completely rid > of XML configs. > > Wishful thinking if you'd ask me. While we surely go to more defaults > and not *requiring* any upfront XML config if the user is satisfied > with those defaults, Java EE is still firmly rooted in XML config. > Quite a lot of configuration scenarios are contextual and not > naturally expressibly in key/value pairs. I can speak for the JSF EG, > and at least in JSF there is no moving to anything other than XML > config (we have in fact discussed this). I'm not aware of anything in > the Servlet EG either. Things like a Filter definition with their > nested init params or security constraints etc are just not that > naturally expressed as key/value pairs. JSON perhaps, but not > key/value. > > I strongly believe there are two main aspects of configuration that > should not be confused: > > 1. Configuring the container > 2. Configuring the application > > Where configuring is a matter of: > > 1. Overlaying XML fragments (in practice mostly a relatively simply > matter of choosing which fragment to include or not) > 2. Providing EL or EL-like placeholders in XML and annotations > 3. Providing key/values (and injecting them info the application) > > Both the container itself and the application can theoretically take > advantage of any of these options, but it practice it seems the > container configuration leans more towards 1, while the application > leans more towards 3. > > I felt that the Java EE configuration JSR, now Tamaya, largely > focussed on providing key/values and a means of injecting them into > the application, and didn't think at all about deployment descriptors > and placeholders in them. > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > >> If DeltaSpike Configuration already covered everything > > > >> there would have been no need for Tamaya;-) > > > > The main goal is to get a JSR running. If we don't achieve this then > there is really not that much benefit in Tamaya. But I am really hopeful > that we DO get this done! > > > > > > > > LieGrue, > > strub > > > > > > > > On Friday, 6 February 2015, 13:34, Werner Keil > wrote: > >> > >>If DeltaSpike Configuration already covered everything there would have > been no need for Tamaya;-) > >> > >> > >>On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms > wrote: > >> > >>Hi, > >>> > >>>On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil > wrote: > >>>> but so far JCP officials first and foremost > >>>> Oracle saw either no need or no resources to do this. > >>> > >>>I remember some other issues being on the table, like Java SE vs Java > >>>EE and "configuring the runtime" vs "injecting/providing values to the > >>>app". > >>> > >>>DeltaSpike Configuration is really great, but it's a value provider. > >>>It doesn't let you swap out or overlay deployment descriptors etc. > >>> > >>>Kind regards, > >>>Arjan Tijms > >>> > >>> > >>> > >>> > >>>> > >>>> Apache Tamaya was a logical result. If that could become a blue-print > or > >>>> initial contribution of a future JSR, let's see, maybe for EE 9. It > uses > >>>> other Apache projects like DeltaSpike where applicable, but may also > define > >>>> such annotations and types of its own, so I suggest you also share > your > >>>> ideas on a Tamaya mailing list or JIRA: > >>>> http://tamaya.incubator.apache.org/index.html > >>>> > >>>> On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >>>>> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (Martin Kouba (JIRA)) > >>>>> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (John Ament (JIRA)) > >>>>> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >>>>> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >>>>> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (James Strachan (JIRA)) > >>>>> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like > >>>>> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) > >>>>> > >>>>> > >>>>> ------------------------------------------------------------ > ---------- > >>>>> > >>>>> Message: 1 > >>>>> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) > >>>>> From: "James Strachan (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> James Strachan created CDI-504: > >>>>> ---------------------------------- > >>>>> > >>>>> Summary: have a standard CDI annotation like > @ConfigProperty > >>>>> from deltapsike > >>>>> Key: CDI-504 > >>>>> URL: https://issues.jboss.org/browse/CDI-504 > >>>>> Project: CDI Specification Issues > >>>>> Issue Type: Feature Request > >>>>> Reporter: James Strachan > >>>>> > >>>>> > >>>>> Docker and containerisation is the new hotness; in the docker world > images > >>>>> are static and the main way of injecting configuration is via > environment > >>>>> variables - so that the same image can be reused but configured at > run time > >>>>> with different configuration values. (Changing configuration files > requires > >>>>> either different images to be created or using custom volumes which > is less > >>>>> ideal in a containerized world). > >>>>> > >>>>> So IMHO CDI should provide a simple, natural way to allow environment > >>>>> variables (or system properties) to be easily injected via CDI. > >>>>> > >>>>> Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> http://deltaspike.apache.org/documentation/configuration.html > >>>>> > >>>>> you can specify a name, default value and use it on an @Inject to > provide > >>>>> a value from env vars, system properties or provide a default. > >>>>> > >>>>> Given how core and useful this is - it feels like it should be part > of the > >>>>> CDI specification; its one simple annotation. > >>>>> > >>>>> Currently deltaspike provides a way to configure different sources > and > >>>>> whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> which was only bound to env vars / system properties. > >>>>> > >>>>> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > >>>>> There could be debate on whether env vars or system properties > should win > >>>>> if the same name is used for both; in a dockerized world I'd prefer > env vars > >>>>> to win but folks can always tinker with their run command to make > sure they > >>>>> pass in env vars as system properties to work around this I guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 2 > >>>>> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) > >>>>> From: "Martin Kouba (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038005#comment-13038005 > >>>>> ] > >>>>> > >>>>> Martin Kouba commented on CDI-504: > >>>>> ---------------------------------- > >>>>> > >>>>> What's wrong with {{java.lang.System.getProperty()}} and > >>>>> {{java.lang.System.getenv()}}? I mean the main advantage of DS > Configuration > >>>>> is IMO the resolution mechanism and the ability to extend the set of > >>>>> {{ConfigSource}} s. If you only need system properties and env > variables a > >>>>> simple producer method and qualifier (or even a simple util method) > would be > >>>>> sufficient. In other words I see no reason to standardize this. > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 3 > >>>>> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) > >>>>> From: "John Ament (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038007#comment-13038007 > >>>>> ] > >>>>> > >>>>> John Ament commented on CDI-504: > >>>>> -------------------------------- > >>>>> > >>>>> A separate config JSR has been proposed previously to address this. > They > >>>>> want to see more options before trying to standardize it. > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 4 > >>>>> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) > >>>>> From: "James Strachan (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038012#comment-13038012 > >>>>> ] > >>>>> > >>>>> James Strachan commented on CDI-504: > >>>>> ------------------------------------ > >>>>> > >>>>> @Resource is supported - injecting values from JNDI. I don't see why > >>>>> injecting values (with a default value) from the environment isn't > also > >>>>> supported too. There's a Java API for JNDI too so folks could look > stuff up > >>>>> in JNDI by hand and do the type conversions - but we've injection > for those > >>>>> values. > >>>>> > >>>>> Its also much cleaner code and can easily deal generically with type > >>>>> conversion to long/double/float/date etc. > >>>>> > >>>>> Compare: > >>>>> {code} > >>>>> @Inject Foo(int bar, ...) { > >>>>> bar = System.getenv("FOO"); > >>>>> if (bar == null) { > >>>>> bar = "someDefault"; > >>>>> } > >>>>> // now convert to a String with error handling.... > >>>>> } > >>>>> {code} > >>>>> to just: > >>>>> {code} > >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >>>>> } > >>>>> {code} > >>>>> > >>>>> Also by using an annotation it means its very easy to generate > >>>>> documentation and tooling. (e.g. using APT you can know what all the > >>>>> environment variables are used by CDI; either to report on demand or > to > >>>>> generate user documentation). > >>>>> > >>>>> > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 5 > >>>>> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) > >>>>> From: "James Strachan (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038012#comment-13038012 > >>>>> ] > >>>>> > >>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: > >>>>> ------------------------------------------------------------- > >>>>> > >>>>> @Resource is supported - injecting values from JNDI. I don't see why > >>>>> injecting values (with a default value) from the environment isn't > also > >>>>> supported too. There's a Java API for JNDI too so folks could look > stuff up > >>>>> in JNDI by hand and do the type conversions - but we've injection > for those > >>>>> values. > >>>>> > >>>>> Its also much cleaner code and can easily deal generically with type > >>>>> conversion to long/double/float/date etc. > >>>>> > >>>>> Compare: > >>>>> {code} > >>>>> @Inject Foo(int bar, ...) { > >>>>> bar = System.getenv("FOO"); > >>>>> if (bar == null) { > >>>>> bar = "someDefault"; > >>>>> } > >>>>> // now convert the String to an int with nice error handling and > >>>>> reporting.... > >>>>> } > >>>>> {code} > >>>>> to just: > >>>>> {code} > >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >>>>> } > >>>>> {code} > >>>>> > >>>>> Also by using an annotation it means its very easy to generate > >>>>> documentation and tooling. (e.g. using APT you can know what all the > >>>>> environment variables are used by CDI; either to report on demand or > to > >>>>> generate user documentation). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> was (Author: jastrachan): > >>>>> @Resource is supported - injecting values from JNDI. I don't see why > >>>>> injecting values (with a default value) from the environment isn't > also > >>>>> supported too. There's a Java API for JNDI too so folks could look > stuff up > >>>>> in JNDI by hand and do the type conversions - but we've injection > for those > >>>>> values. > >>>>> > >>>>> Its also much cleaner code and can easily deal generically with type > >>>>> conversion to long/double/float/date etc. > >>>>> > >>>>> Compare: > >>>>> {code} > >>>>> @Inject Foo(int bar, ...) { > >>>>> bar = System.getenv("FOO"); > >>>>> if (bar == null) { > >>>>> bar = "someDefault"; > >>>>> } > >>>>> // now convert to a String with error handling.... > >>>>> } > >>>>> {code} > >>>>> to just: > >>>>> {code} > >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >>>>> } > >>>>> {code} > >>>>> > >>>>> Also by using an annotation it means its very easy to generate > >>>>> documentation and tooling. (e.g. using APT you can know what all the > >>>>> environment variables are used by CDI; either to report on demand or > to > >>>>> generate user documentation). > >>>>> > >>>>> > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 6 > >>>>> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) > >>>>> From: "James Strachan (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038012#comment-13038012 > >>>>> ] > >>>>> > >>>>> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: > >>>>> ------------------------------------------------------------- > >>>>> > >>>>> @Resource is supported - injecting values from JNDI. I don't see why > >>>>> injecting values (with a default value) from the environment isn't > also > >>>>> supported too. There's a Java API for JNDI too so folks could look > stuff up > >>>>> in JNDI by hand and do the type conversions - but we've injection > for those > >>>>> values. > >>>>> > >>>>> Its also much cleaner code and can easily deal generically with type > >>>>> conversion to long/double/float/date etc. > >>>>> > >>>>> Compare: > >>>>> {code} > >>>>> int bar; > >>>>> @Inject Foo() { > >>>>> barText = System.getenv("FOO"); > >>>>> if (barText == null) { > >>>>> barText = "someDefault"; > >>>>> } > >>>>> // now convert the String to an int with nice error handling and > >>>>> reporting.... > >>>>> bar = someConvertCode(barText); > >>>>> } > >>>>> {code} > >>>>> to just: > >>>>> {code} > >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >>>>> } > >>>>> {code} > >>>>> > >>>>> Note that in the second case, folks could use the constructor > explicitly > >>>>> without being bound to environment variables too; much cleaner, more > modular > >>>>> code. > >>>>> > >>>>> Also by using an annotation it means its very easy to generate > >>>>> documentation and tooling. (e.g. using APT you can know what all the > >>>>> environment variables are used by CDI; either to report on demand or > to > >>>>> generate user documentation). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> was (Author: jastrachan): > >>>>> @Resource is supported - injecting values from JNDI. I don't see why > >>>>> injecting values (with a default value) from the environment isn't > also > >>>>> supported too. There's a Java API for JNDI too so folks could look > stuff up > >>>>> in JNDI by hand and do the type conversions - but we've injection > for those > >>>>> values. > >>>>> > >>>>> Its also much cleaner code and can easily deal generically with type > >>>>> conversion to long/double/float/date etc. > >>>>> > >>>>> Compare: > >>>>> {code} > >>>>> @Inject Foo(int bar, ...) { > >>>>> bar = System.getenv("FOO"); > >>>>> if (bar == null) { > >>>>> bar = "someDefault"; > >>>>> } > >>>>> // now convert the String to an int with nice error handling and > >>>>> reporting.... > >>>>> } > >>>>> {code} > >>>>> to just: > >>>>> {code} > >>>>> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { > >>>>> } > >>>>> {code} > >>>>> > >>>>> Also by using an annotation it means its very easy to generate > >>>>> documentation and tooling. (e.g. using APT you can know what all the > >>>>> environment variables are used by CDI; either to report on demand or > to > >>>>> generate user documentation). > >>>>> > >>>>> > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 7 > >>>>> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) > >>>>> From: "Antoine Sabot-Durand (JIRA)" > >>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI > >>>>> annotation like @ConfigProperty from deltapsike > >>>>> To: cdi-dev at lists.jboss.org > >>>>> Message-ID: > >>>>> JIRA> > >>>>> Content-Type: text/plain; charset=UTF-8 > >>>>> > >>>>> > >>>>> [ > >>>>> https://issues.jboss.org/browse/CDI-504?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13038271#comment-13038271 > >>>>> ] > >>>>> > >>>>> Antoine Sabot-Durand commented on CDI-504: > >>>>> ------------------------------------------ > >>>>> > >>>>> James, I don't get what's the problem with using DeltaSpike config > >>>>> solution? > >>>>> > >>>>> > have a standard CDI annotation like @ConfigProperty from deltapsike > >>>>> > ------------------------------------------------------------ > ------- > >>>>> > > >>>>> > Key: CDI-504 > >>>>> > URL: https://issues.jboss.org/browse/CDI-504 > >>>>> > Project: CDI Specification Issues > >>>>> > Issue Type: Feature Request > >>>>> > Reporter: James Strachan > >>>>> > > >>>>> > Docker and containerisation is the new hotness; in the docker world > >>>>> > images are static and the main way of injecting configuration is > via > >>>>> > environment variables - so that the same image can be reused but > configured > >>>>> > at run time with different configuration values. (Changing > configuration > >>>>> > files requires either different images to be created or using > custom volumes > >>>>> > which is less ideal in a containerized world). > >>>>> > So IMHO CDI should provide a simple, natural way to allow > environment > >>>>> > variables (or system properties) to be easily injected via CDI. > >>>>> > Delta Spike as a @ConfigProperty annotation which works very nicely > >>>>> > http://deltaspike.apache.org/documentation/configuration.html > >>>>> > you can specify a name, default value and use it on an @Inject to > >>>>> > provide a value from env vars, system properties or provide a > default. > >>>>> > Given how core and useful this is - it feels like it should be > part of > >>>>> > the CDI specification; its one simple annotation. > >>>>> > Currently deltaspike provides a way to configure different sources > and > >>>>> > whatnot which is cool; I'd be happy if CDI just had a simpler > annotation > >>>>> > which was only bound to env vars / system properties. > >>>>> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > >>>>> > There could be debate on whether env vars or system properties > should > >>>>> > win if the same name is used for both; in a dockerized world I'd > prefer env > >>>>> > vars to win but folks can always tinker with their run command to > make sure > >>>>> > they pass in env vars as system properties to work around this I > guess. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian JIRA > >>>>> (v6.3.11#6341) > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 51, Issue 9 > >>>>> ************************************** > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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. > >> > >> > > _______________________________________________ > 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/20150209/6ceac598/attachment-0001.html From issues at jboss.org Mon Feb 9 10:22:50 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 9 Feb 2015 10:22:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038834#comment-13038834 ] Mark Struberg commented on CDI-504: ----------------------------------- -1 for including this now. We will simply just end up with a half backed solution. I'd suggest to look at the Apache Tamaya project which is basically a spun out and minimalistic version of the DeltaSpike configuration system plus a few nice additions. The goal is to get this ready to be proposed as JSR in a few months. Tamaya does mainly target SE, so it's pure java without DI. But the DI part can easily bet put on top of it. It actually doesn't matter if that would be part of a config JSR or CDI-2. I just like to avoid a situation like we had with @ManagedBean. 3 annotations in 3 different packages and none of them is really working in practice... > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Mon Feb 9 12:28:55 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 9 Feb 2015 18:28:55 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <2145261667.1123409.1423479607446.JavaMail.yahoo@mail.yahoo.com> References: <2145261667.1123409.1423479607446.JavaMail.yahoo@mail.yahoo.com> Message-ID: <89BB9BE8-234D-49BC-B813-7221698B4439@sabot-durand.net> Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec. So could we figure something user friendly to enable async event? Antoine > Le 9 f?vr. 2015 ? 12:00, Mark Struberg a ?crit : > > But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. > > Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... > > That will leave us half-broken as it totally defeats the usage of this cool feature... > > LieGrue, > strub > > > > > >> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: >>> Mark, >> >> >> During last meeting we didn?t say there wasn?t use case that would break >> existing observer, we said that since we keep the current fire() method there is >> backward compatibility. User trying to send fireAsync() and experiencing error >> with legacy observer will have to fall back to fire(). >> >> Antoine >> >> >> >>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >>> >>> Hi Jozef, here we go! >>> >>> >>> 1.) accessing @RequestScoped beans in your Observer >>> >>> 2.) accessing @SessionScoped beans in your Observer >>> 3.) accessing/relying on any transactional behaviour. This is really a >> boomer. Basically you break transactions that way. >>> >>> 4.) accessing @TransactionScoped beans in your Observer >>> >>> 5.) access/relying on any ThreadLocal in your Observer >>> 6.) accessing attached entities in your Observers (they must only get >> accessed from a very single Thread according to the JPA spec) >>> 7.) using an EntityManager in a parallel thread might give you unexpected >> results. >>> >>> >>> There might be quite a few more. E.g. we need to specify that EJBs and >> other EE features need to work in such a new Thread, etc >>> >>> >>> LieGrue, >>> strub >>> >>> >>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >> wrote: >>> >>> >>>> >>>> >>>> We should enumerate all the arguments supporting async flag on an >> observer. So far I have only seen one: >>>> >>>> - an observer accessing @RequestScoped state would no longer be able >>> to do so since it would be run in a worker thread >>>> >>>> I am eager to hear more arguments as this single one may not be >>> enough to justify the observer-async-flag design decision. >>>> >>>> Remember that introducing fireAsync() itself does not break any >>> existing application because existing applications are using fire(). >>> It's when an existing application / library is modified to use >>> fireAsync() when the problem may occur. Such change should not be >>> done blindly. As with any other change, an author should consider >>> possible consequences of the change. Clearly documenting the fact >>> that fireAsync() processing is done in a different thread with a >>> different @RequestScoped state may be sufficient. >>>> >>>> Jozef >>>> >>>> >>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>> >>>> Hi all, >>>>> >>>>> >>>>> >>>>> >>>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of >> discussion about async events. >>>>> >>>>> >>>>> I think the solution exposed here is quite satisfying, yet the idea >> to need to activate async behaviour on the observer side doesn?t please a lot of >> us. It?ll be confusing for users to have to activate async from the firing end >> and consuming end to see it work :-(. >>>>> >>>>> >>>>> I?d like to see alternative proposal to have this new feature as >> user friendly as possible and keep the retro-compatibility aspect. We should >> find a better solution on our next meeting on wednesday. >>>>> >>>>> >>>>> 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. >>>> >>>> _______________________________________________ >>>> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150209/21af0962/attachment.bin From rmannibucau at gmail.com Mon Feb 9 12:43:55 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 9 Feb 2015 18:43:55 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <89BB9BE8-234D-49BC-B813-7221698B4439@sabot-durand.net> References: <2145261667.1123409.1423479607446.JavaMail.yahoo@mail.yahoo.com> <89BB9BE8-234D-49BC-B813-7221698B4439@sabot-durand.net> Message-ID: Guys I'm not sure to fully get the jira description now. Can you try to rephrase it a bit? Here what I see: 1) fireAsync (+1) is clear 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I think this API is not usable (=user friendly) and I would just suggest it is on by default and to remove this flag Can it break apps? Yes as mentionned by Mark. Will it break apps? No since it is not yet used and this is surely what we want. I fully understand all the mentionned pitfalls - but let me say @RequestScoped is by definition as broken as this today since you can't associate it with a request for the exact same reason. What I mean is: if you choose async then you assume it so I think we shouldn't protect the user from pitfalls then...in particular since we can't protect him from other as vicious issues. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand : > Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec. > > So could we figure something user friendly to enable async event? > > Antoine > > >> Le 9 f?vr. 2015 ? 12:00, Mark Struberg a ?crit : >> >> But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. >> >> Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... >> >> That will leave us half-broken as it totally defeats the usage of this cool feature... >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: >>>> Mark, >>> >>> >>> During last meeting we didn?t say there wasn?t use case that would break >>> existing observer, we said that since we keep the current fire() method there is >>> backward compatibility. User trying to send fireAsync() and experiencing error >>> with legacy observer will have to fall back to fire(). >>> >>> Antoine >>> >>> >>> >>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >>>> >>>> Hi Jozef, here we go! >>>> >>>> >>>> 1.) accessing @RequestScoped beans in your Observer >>>> >>>> 2.) accessing @SessionScoped beans in your Observer >>>> 3.) accessing/relying on any transactional behaviour. This is really a >>> boomer. Basically you break transactions that way. >>>> >>>> 4.) accessing @TransactionScoped beans in your Observer >>>> >>>> 5.) access/relying on any ThreadLocal in your Observer >>>> 6.) accessing attached entities in your Observers (they must only get >>> accessed from a very single Thread according to the JPA spec) >>>> 7.) using an EntityManager in a parallel thread might give you unexpected >>> results. >>>> >>>> >>>> There might be quite a few more. E.g. we need to specify that EJBs and >>> other EE features need to work in such a new Thread, etc >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>> wrote: >>>> >>>> >>>>> >>>>> >>>>> We should enumerate all the arguments supporting async flag on an >>> observer. So far I have only seen one: >>>>> >>>>> - an observer accessing @RequestScoped state would no longer be able >>>> to do so since it would be run in a worker thread >>>>> >>>>> I am eager to hear more arguments as this single one may not be >>>> enough to justify the observer-async-flag design decision. >>>>> >>>>> Remember that introducing fireAsync() itself does not break any >>>> existing application because existing applications are using fire(). >>>> It's when an existing application / library is modified to use >>>> fireAsync() when the problem may occur. Such change should not be >>>> done blindly. As with any other change, an author should consider >>>> possible consequences of the change. Clearly documenting the fact >>>> that fireAsync() processing is done in a different thread with a >>>> different @RequestScoped state may be sufficient. >>>>> >>>>> Jozef >>>>> >>>>> >>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of >>> discussion about async events. >>>>>> >>>>>> >>>>>> I think the solution exposed here is quite satisfying, yet the idea >>> to need to activate async behaviour on the observer side doesn?t please a lot of >>> us. It?ll be confusing for users to have to activate async from the firing end >>> and consuming end to see it work :-(. >>>>>> >>>>>> >>>>>> I?d like to see alternative proposal to have this new feature as >>> user friendly as possible and keep the retro-compatibility aspect. We should >>> find a better solution on our next meeting on wednesday. >>>>>> >>>>>> >>>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> 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 struberg at yahoo.de Mon Feb 9 14:33:21 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Feb 2015 19:33:21 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: Message-ID: <923477804.1302763.1423510401344.JavaMail.yahoo@mail.yahoo.com> Btw, did we already cover the 'fireAndForget' vs 'fireAndWait' use cases? 1. fireAndForget: this is basically what you get today if you use @javax.ejb.Asynchronous on an @Observer method 2.) fireAndWait: call all observers in a new thread and only return after all observer methods did finish. Did we already agree on one of the 2 modi? If not, do we like to support both? And if so, how to tell the CDI container which of the 2 modes to use for each observer? If you answer the last question with yes then we might need some annotation/additional info on the observer method anyway. And then we are back on our @Async annotation on the observer method... LieGrue, strub On Monday, 9 February 2015, 18:43, Romain Manni-Bucau wrote: >Guys I'm not sure to fully get the jira description now. Can you try >to rephrase it a bit? > >Here what I see: > >1) fireAsync (+1) is clear >2) (part I dont fully get) asyncSupported: is it mandatory? If yes I >think this API is not usable (=user friendly) and I would just suggest >it is on by default and to remove this flag > > >Can it break apps? Yes as mentionned by Mark. Will it break apps? No >since it is not yet used and this is surely what we want. I fully >understand all the mentionned pitfalls - but let me say @RequestScoped >is by definition as broken as this today since you can't associate it >with a request for the exact same reason. What I mean is: if you >choose async then you assume it so I think we shouldn't protect the >user from pitfalls then...in particular since we can't protect him >from other as vicious issues. > > > > > >Romain Manni-Bucau >@rmannibucau >http://www.tomitribe.com >http://rmannibucau.wordpress.com >https://github.com/rmannibucau > > >2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand : >> Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec. >> >> So could we figure something user friendly to enable async event? >> >> Antoine >> >> >>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg a ?crit : >>> >>> But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. >>> >>> Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... >>> >>> That will leave us half-broken as it totally defeats the usage of this cool feature... >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: >>>>> Mark, >>>> >>>> >>>> During last meeting we didn?t say there wasn?t use case that would break >>>> existing observer, we said that since we keep the current fire() method there is >>>> backward compatibility. User trying to send fireAsync() and experiencing error >>>> with legacy observer will have to fall back to fire(). >>>> >>>> Antoine >>>> >>>> >>>> >>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >>>>> >>>>> Hi Jozef, here we go! >>>>> >>>>> >>>>> 1.) accessing @RequestScoped beans in your Observer >>>>> >>>>> 2.) accessing @SessionScoped beans in your Observer >>>>> 3.) accessing/relying on any transactional behaviour. This is really a >>>> boomer. Basically you break transactions that way. >>>>> >>>>> 4.) accessing @TransactionScoped beans in your Observer >>>>> >>>>> 5.) access/relying on any ThreadLocal in your Observer >>>>> 6.) accessing attached entities in your Observers (they must only get >>>> accessed from a very single Thread according to the JPA spec) >>>>> 7.) using an EntityManager in a parallel thread might give you unexpected >>>> results. >>>>> >>>>> >>>>> There might be quite a few more. E.g. we need to specify that EJBs and >>>> other EE features need to work in such a new Thread, etc >>>>> >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>>> wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> We should enumerate all the arguments supporting async flag on an >>>> observer. So far I have only seen one: >>>>>> >>>>>> - an observer accessing @RequestScoped state would no longer be able >>>>> to do so since it would be run in a worker thread >>>>>> >>>>>> I am eager to hear more arguments as this single one may not be >>>>> enough to justify the observer-async-flag design decision. >>>>>> >>>>>> Remember that introducing fireAsync() itself does not break any >>>>> existing application because existing applications are using fire(). >>>>> It's when an existing application / library is modified to use >>>>> fireAsync() when the problem may occur. Such change should not be >>>>> done blindly. As with any other change, an author should consider >>>>> possible consequences of the change. Clearly documenting the fact >>>>> that fireAsync() processing is done in a different thread with a >>>>> different @RequestScoped state may be sufficient. >>>>>> >>>>>> Jozef >>>>>> >>>>>> >>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>>> >>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of >>>> discussion about async events. >>>>>>> >>>>>>> >>>>>>> I think the solution exposed here is quite satisfying, yet the idea >>>> to need to activate async behaviour on the observer side doesn?t please a lot of >>>> us. It?ll be confusing for users to have to activate async from the firing end >>>> and consuming end to see it work :-(. >>>>>>> >>>>>>> >>>>>>> I?d like to see alternative proposal to have this new feature as >>>> user friendly as possible and keep the retro-compatibility aspect. We should >>>> find a better solution on our next meeting on wednesday. >>>>>>> >>>>>>> >>>>>>> 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. > >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Mon Feb 9 14:56:08 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 9 Feb 2015 20:56:08 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <923477804.1302763.1423510401344.JavaMail.yahoo@mail.yahoo.com> References: <923477804.1302763.1423510401344.JavaMail.yahoo@mail.yahoo.com> Message-ID: I guess 2 is not a real need - and at least not why people voted for this feature. Difference between fireAsync and @Async is who decides to be asynchronous. Caller (fire) should clearly be able IMO - with all the warning we can put in the spec to say it should be done with compatible scopes. The second one is less important for me cause you can already do it with concurrency utilities (ee one or not) pretty easily. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-09 20:33 GMT+01:00 Mark Struberg : > Btw, did we already cover the 'fireAndForget' vs 'fireAndWait' use cases? > > 1. fireAndForget: this is basically what you get today if you use @javax.ejb.Asynchronous on an @Observer method > > 2.) fireAndWait: call all observers in a new thread and only return after all observer methods did finish. > > > > Did we already agree on one of the 2 modi? If not, do we like to support both? And if so, how to tell the CDI container which of the 2 modes to use for each observer? > > > If you answer the last question with yes then we might need some annotation/additional info on the observer method anyway. And then we are back on our @Async annotation on the observer method... > > > LieGrue, > strub > > > On Monday, 9 February 2015, 18:43, Romain Manni-Bucau wrote: >>Guys I'm not sure to fully get the jira description now. Can you try >>to rephrase it a bit? >> >>Here what I see: >> >>1) fireAsync (+1) is clear >>2) (part I dont fully get) asyncSupported: is it mandatory? If yes I >>think this API is not usable (=user friendly) and I would just suggest >>it is on by default and to remove this flag >> >> >>Can it break apps? Yes as mentionned by Mark. Will it break apps? No >>since it is not yet used and this is surely what we want. I fully >>understand all the mentionned pitfalls - but let me say @RequestScoped >>is by definition as broken as this today since you can't associate it >>with a request for the exact same reason. What I mean is: if you >>choose async then you assume it so I think we shouldn't protect the >>user from pitfalls then...in particular since we can't protect him >>from other as vicious issues. >> >> >> >> >> >>Romain Manni-Bucau >>@rmannibucau >>http://www.tomitribe.com >>http://rmannibucau.wordpress.com >>https://github.com/rmannibucau >> >> >>2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand : >>> Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec. >>> >>> So could we figure something user friendly to enable async event? >>> >>> Antoine >>> >>> >>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg a ?crit : >>>> >>>> But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. >>>> >>>> Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... >>>> >>>> That will leave us half-broken as it totally defeats the usage of this cool feature... >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> >>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: >>>>>> Mark, >>>>> >>>>> >>>>> During last meeting we didn?t say there wasn?t use case that would break >>>>> existing observer, we said that since we keep the current fire() method there is >>>>> backward compatibility. User trying to send fireAsync() and experiencing error >>>>> with legacy observer will have to fall back to fire(). >>>>> >>>>> Antoine >>>>> >>>>> >>>>> >>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >>>>>> >>>>>> Hi Jozef, here we go! >>>>>> >>>>>> >>>>>> 1.) accessing @RequestScoped beans in your Observer >>>>>> >>>>>> 2.) accessing @SessionScoped beans in your Observer >>>>>> 3.) accessing/relying on any transactional behaviour. This is really a >>>>> boomer. Basically you break transactions that way. >>>>>> >>>>>> 4.) accessing @TransactionScoped beans in your Observer >>>>>> >>>>>> 5.) access/relying on any ThreadLocal in your Observer >>>>>> 6.) accessing attached entities in your Observers (they must only get >>>>> accessed from a very single Thread according to the JPA spec) >>>>>> 7.) using an EntityManager in a parallel thread might give you unexpected >>>>> results. >>>>>> >>>>>> >>>>>> There might be quite a few more. E.g. we need to specify that EJBs and >>>>> other EE features need to work in such a new Thread, etc >>>>>> >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>>>> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> We should enumerate all the arguments supporting async flag on an >>>>> observer. So far I have only seen one: >>>>>>> >>>>>>> - an observer accessing @RequestScoped state would no longer be able >>>>>> to do so since it would be run in a worker thread >>>>>>> >>>>>>> I am eager to hear more arguments as this single one may not be >>>>>> enough to justify the observer-async-flag design decision. >>>>>>> >>>>>>> Remember that introducing fireAsync() itself does not break any >>>>>> existing application because existing applications are using fire(). >>>>>> It's when an existing application / library is modified to use >>>>>> fireAsync() when the problem may occur. Such change should not be >>>>>> done blindly. As with any other change, an author should consider >>>>>> possible consequences of the change. Clearly documenting the fact >>>>>> that fireAsync() processing is done in a different thread with a >>>>>> different @RequestScoped state may be sufficient. >>>>>>> >>>>>>> Jozef >>>>>>> >>>>>>> >>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>>>> >>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of >>>>> discussion about async events. >>>>>>>> >>>>>>>> >>>>>>>> I think the solution exposed here is quite satisfying, yet the idea >>>>> to need to activate async behaviour on the observer side doesn?t please a lot of >>>>> us. It?ll be confusing for users to have to activate async from the firing end >>>>> and consuming end to see it work :-(. >>>>>>>> >>>>>>>> >>>>>>>> I?d like to see alternative proposal to have this new feature as >>>>> user friendly as possible and keep the retro-compatibility aspect. We should >>>>> find a better solution on our next meeting on wednesday. >>>>>>>> >>>>>>>> >>>>>>>> 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. >> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. >> >> > > _______________________________________________ > 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 struberg at yahoo.de Tue Feb 10 01:35:01 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 06:35:01 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: Message-ID: <1531960065.1474603.1423550101846.JavaMail.yahoo@mail.yahoo.com> Good morning! Folks, please think a bit further. I'll give you a practical example. What should a developer do first? Eat their own dog food... Where does this apply to us? Means where do _we_ use CDI events? Right, in CDI Extensions. So ask yourself a simple question: if we like to leverage async events in CDI extensions then how could we do that? Your suggestion was to just use fireAsync instead of fire, right? Now imagine what would happen if we would do that... I'd say most real world apps would go BOOOOMMMMM and not even finish the start. Simply because most CDI extensions are not built to be executed in parallel. Just look at Extensions who collect information about classes in @Observes ProcessAnnotatedType. Most of the time they collect this in a non-concurrent Set or List private final Collection> messageBundleTypes = new HashSet>(); If you fire the ProcessAnnotatedType event in parallel then you will blow up. And this was just ONE example. There are tons of other CDI Extension Events which would have the same result if switched to fireAsync. Now think about what would happen IF we would have an @Async on the observer? All would work. Old extensions still will get triggered in the same thread, but extensions with @Async would leverage parallel behaviour. I hope this practical sample makes it more clear why I think that most of the time we cannot simply switch to fireAsync if there is old code around which is not under your full control. LieGrue, strub > On Monday, 9 February 2015, 20:56, Romain Manni-Bucau wrote: > > I guess 2 is not a real need - and at least not why people voted for > this feature. Difference between fireAsync and @Async is who decides > to be asynchronous. Caller (fire) should clearly be able IMO - with > all the warning we can put in the spec to say it should be done with > compatible scopes. The second one is less important for me cause you > can already do it with concurrency utilities (ee one or not) pretty > easily. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-09 20:33 GMT+01:00 Mark Struberg : >> Btw, did we already cover the 'fireAndForget' vs > 'fireAndWait' use cases? >> >> 1. fireAndForget: this is basically what you get today if you use > @javax.ejb.Asynchronous on an @Observer method >> >> 2.) fireAndWait: call all observers in a new thread and only return after > all observer methods did finish. >> >> >> >> Did we already agree on one of the 2 modi? If not, do we like to support > both? And if so, how to tell the CDI container which of the 2 modes to use for > each observer? >> >> >> If you answer the last question with yes then we might need some > annotation/additional info on the observer method anyway. And then we are back > on our @Async annotation on the observer method... >> >> >> LieGrue, >> strub >> >> >> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau > wrote: >>> Guys I'm not sure to fully get the jira description now. Can you try >>> to rephrase it a bit? >>> >>> Here what I see: >>> >>> 1) fireAsync (+1) is clear >>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I >>> think this API is not usable (=user friendly) and I would just suggest >>> it is on by default and to remove this flag >>> >>> >>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No >>> since it is not yet used and this is surely what we want. I fully >>> understand all the mentionned pitfalls - but let me say @RequestScoped >>> is by definition as broken as this today since you can't associate > it >>> with a request for the exact same reason. What I mean is: if you >>> choose async then you assume it so I think we shouldn't protect the >>> user from pitfalls then...in particular since we can't protect him >>> from other as vicious issues. >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand > : >>>> Mark I understand your concern, now can you understand the one we > discussed about the fact of having to enable async at both ends is a source of > confusion for end users and will give a bad perception of the spec. >>>> >>>> So could we figure something user friendly to enable async event? >>>> >>>> Antoine >>>> >>>> >>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg > a ?crit : >>>>> >>>>> But that might defeat pluggabilgity. Basically no framework can > use fireAsync in that case. >>>>> >>>>> Imagine a UserLoggedIn event. For most observers it is > perfectly fine to observe this in a new thread. But some might need to access > the session -> boom. Which means that all frameworks have to fall back to the > 'safe' fire() instead of fireAsync()... >>>>> >>>>> That will leave us half-broken as it totally defeats the usage > of this cool feature... >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand > wrote: >>>>>>> Mark, >>>>>> >>>>>> >>>>>> During last meeting we didn?t say there wasn?t use case > that would break >>>>>> existing observer, we said that since we keep the current > fire() method there is >>>>>> backward compatibility. User trying to send fireAsync() and > experiencing error >>>>>> with legacy observer will have to fall back to fire(). >>>>>> >>>>>> Antoine >>>>>> >>>>>> >>>>>> >>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg > a ?crit : >>>>>>> >>>>>>> Hi Jozef, here we go! >>>>>>> >>>>>>> >>>>>>> 1.) accessing @RequestScoped beans in your Observer >>>>>>> >>>>>>> 2.) accessing @SessionScoped beans in your Observer >>>>>>> 3.) accessing/relying on any transactional behaviour. > This is really a >>>>>> boomer. Basically you break transactions that way. >>>>>>> >>>>>>> 4.) accessing @TransactionScoped beans in your Observer >>>>>>> >>>>>>> 5.) access/relying on any ThreadLocal in your Observer >>>>>>> 6.) accessing attached entities in your Observers (they > must only get >>>>>> accessed from a very single Thread according to the JPA > spec) >>>>>>> 7.) using an EntityManager in a parallel thread might > give you unexpected >>>>>> results. >>>>>>> >>>>>>> >>>>>>> There might be quite a few more. E.g. we need to > specify that EJBs and >>>>>> other EE features need to work in such a new Thread, etc >>>>>>> >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We should enumerate all the arguments supporting > async flag on an >>>>>> observer. So far I have only seen one: >>>>>>>> >>>>>>>> - an observer accessing @RequestScoped state would > no longer be able >>>>>>> to do so since it would be run in a worker thread >>>>>>>> >>>>>>>> I am eager to hear more arguments as this single > one may not be >>>>>>> enough to justify the observer-async-flag design > decision. >>>>>>>> >>>>>>>> Remember that introducing fireAsync() itself does > not break any >>>>>>> existing application because existing applications > are using fire(). >>>>>>> It's when an existing application / library is > modified to use >>>>>>> fireAsync() when the problem may occur. Such change > should not be >>>>>>> done blindly. As with any other change, an author > should consider >>>>>>> possible consequences of the change. Clearly > documenting the fact >>>>>>> that fireAsync() processing is done in a different > thread with a >>>>>>> different @RequestScoped state may be sufficient. >>>>>>>> >>>>>>>> Jozef >>>>>>>> >>>>>>>> >>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://issues.jboss.org/browse/CDI-499 comes > after a lot of >>>>>> discussion about async events. >>>>>>>>> >>>>>>>>> >>>>>>>>> I think the solution exposed here is quite > satisfying, yet the idea >>>>>> to need to activate async behaviour on the observer side > doesn?t please a lot of >>>>>> us. It?ll be confusing for users to have to activate async > from the firing end >>>>>> and consuming end to see it work :-(. >>>>>>>>> >>>>>>>>> >>>>>>>>> I?d like to see alternative proposal to have > this new feature as >>>>>> user friendly as possible and keep the retro-compatibility > aspect. We should >>>>>> find a better solution on our next meeting on wednesday. >>>>>>>>> >>>>>>>>> >>>>>>>>> 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. > >>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. >>> >>> >> >> _______________________________________________ >> 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 jose.paumard at gmail.com Tue Feb 10 02:41:15 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Tue, 10 Feb 2015 08:41:15 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <1531960065.1474603.1423550101846.JavaMail.yahoo@mail.yahoo.com> References: <1531960065.1474603.1423550101846.JavaMail.yahoo@mail.yahoo.com> Message-ID: Mark, It vas never been in the mind of anyone to modify the way things work currently. Keeping the backward compatibility is a prerequisite to any kind of modification or improvment added to the spec. This has already been said and written several times. Jos? Le 10 f?vr. 2015 07:37, "Mark Struberg" a ?crit : > Good morning! > > > Folks, please think a bit further. > > > I'll give you a practical example. What should a developer do first? Eat > their own dog food... > > Where does this apply to us? Means where do _we_ use CDI events? Right, in > CDI Extensions. > > So ask yourself a simple question: if we like to leverage async events in > CDI extensions then how could we do that? Your suggestion was to just use > fireAsync instead of fire, right? > > Now imagine what would happen if we would do that... I'd say most real > world apps would go BOOOOMMMMM and not even finish the start. Simply > because most CDI extensions are not built to be executed in parallel. Just > look at Extensions who collect information about classes in @Observes > ProcessAnnotatedType. Most of the time they collect this in a > non-concurrent Set or List > > private final Collection> messageBundleTypes = new > HashSet>(); > > > If you fire the ProcessAnnotatedType event in parallel then you will blow > up. And this was just ONE example. There are tons of other CDI Extension > Events which would have the same result if switched to fireAsync. > > > Now think about what would happen IF we would have an @Async on the > observer? > > All would work. Old extensions still will get triggered in the same > thread, but extensions with @Async would leverage parallel behaviour. > > > I hope this practical sample makes it more clear why I think that most of > the time we cannot simply switch to fireAsync if there is old code around > which is not under your full control. > > > LieGrue, > strub > > > > > > > > On Monday, 9 February 2015, 20:56, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > > > I guess 2 is not a real need - and at least not why people voted for > > this feature. Difference between fireAsync and @Async is who decides > > to be asynchronous. Caller (fire) should clearly be able IMO - with > > all the warning we can put in the spec to say it should be done with > > compatible scopes. The second one is less important for me cause you > > can already do it with concurrency utilities (ee one or not) pretty > > easily. > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2015-02-09 20:33 GMT+01:00 Mark Struberg : > >> Btw, did we already cover the 'fireAndForget' vs > > 'fireAndWait' use cases? > >> > >> 1. fireAndForget: this is basically what you get today if you use > > @javax.ejb.Asynchronous on an @Observer method > >> > >> 2.) fireAndWait: call all observers in a new thread and only return > after > > all observer methods did finish. > >> > >> > >> > >> Did we already agree on one of the 2 modi? If not, do we like to > support > > both? And if so, how to tell the CDI container which of the 2 modes to > use for > > each observer? > >> > >> > >> If you answer the last question with yes then we might need some > > annotation/additional info on the observer method anyway. And then we > are back > > on our @Async annotation on the observer method... > >> > >> > >> LieGrue, > >> strub > >> > >> > >> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau > > wrote: > >>> Guys I'm not sure to fully get the jira description now. Can you try > >>> to rephrase it a bit? > >>> > >>> Here what I see: > >>> > >>> 1) fireAsync (+1) is clear > >>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I > >>> think this API is not usable (=user friendly) and I would just suggest > >>> it is on by default and to remove this flag > >>> > >>> > >>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No > >>> since it is not yet used and this is surely what we want. I fully > >>> understand all the mentionned pitfalls - but let me say @RequestScoped > >>> is by definition as broken as this today since you can't associate > > it > >>> with a request for the exact same reason. What I mean is: if you > >>> choose async then you assume it so I think we shouldn't protect the > >>> user from pitfalls then...in particular since we can't protect him > >>> from other as vicious issues. > >>> > >>> > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand > > : > >>>> Mark I understand your concern, now can you understand the one we > > discussed about the fact of having to enable async at both ends is a > source of > > confusion for end users and will give a bad perception of the spec. > >>>> > >>>> So could we figure something user friendly to enable async event? > >>>> > >>>> Antoine > >>>> > >>>> > >>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg > > a ?crit : > >>>>> > >>>>> But that might defeat pluggabilgity. Basically no framework can > > use fireAsync in that case. > >>>>> > >>>>> Imagine a UserLoggedIn event. For most observers it is > > perfectly fine to observe this in a new thread. But some might need to > access > > the session -> boom. Which means that all frameworks have to fall back > to the > > 'safe' fire() instead of fireAsync()... > >>>>> > >>>>> That will leave us half-broken as it totally defeats the usage > > of this cool feature... > >>>>> > >>>>> LieGrue, > >>>>> strub > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand > > wrote: > >>>>>>> Mark, > >>>>>> > >>>>>> > >>>>>> During last meeting we didn?t say there wasn?t use case > > that would break > >>>>>> existing observer, we said that since we keep the current > > fire() method there is > >>>>>> backward compatibility. User trying to send fireAsync() and > > experiencing error > >>>>>> with legacy observer will have to fall back to fire(). > >>>>>> > >>>>>> Antoine > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg > > a ?crit : > >>>>>>> > >>>>>>> Hi Jozef, here we go! > >>>>>>> > >>>>>>> > >>>>>>> 1.) accessing @RequestScoped beans in your Observer > >>>>>>> > >>>>>>> 2.) accessing @SessionScoped beans in your Observer > >>>>>>> 3.) accessing/relying on any transactional behaviour. > > This is really a > >>>>>> boomer. Basically you break transactions that way. > >>>>>>> > >>>>>>> 4.) accessing @TransactionScoped beans in your Observer > >>>>>>> > >>>>>>> 5.) access/relying on any ThreadLocal in your Observer > >>>>>>> 6.) accessing attached entities in your Observers (they > > must only get > >>>>>> accessed from a very single Thread according to the JPA > > spec) > >>>>>>> 7.) using an EntityManager in a parallel thread might > > give you unexpected > >>>>>> results. > >>>>>>> > >>>>>>> > >>>>>>> There might be quite a few more. E.g. we need to > > specify that EJBs and > >>>>>> other EE features need to work in such a new Thread, etc > >>>>>>> > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> > >>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> We should enumerate all the arguments supporting > > async flag on an > >>>>>> observer. So far I have only seen one: > >>>>>>>> > >>>>>>>> - an observer accessing @RequestScoped state would > > no longer be able > >>>>>>> to do so since it would be run in a worker thread > >>>>>>>> > >>>>>>>> I am eager to hear more arguments as this single > > one may not be > >>>>>>> enough to justify the observer-async-flag design > > decision. > >>>>>>>> > >>>>>>>> Remember that introducing fireAsync() itself does > > not break any > >>>>>>> existing application because existing applications > > are using fire(). > >>>>>>> It's when an existing application / library is > > modified to use > >>>>>>> fireAsync() when the problem may occur. Such change > > should not be > >>>>>>> done blindly. As with any other change, an author > > should consider > >>>>>>> possible consequences of the change. Clearly > > documenting the fact > >>>>>>> that fireAsync() processing is done in a different > > thread with a > >>>>>>> different @RequestScoped state may be sufficient. > >>>>>>>> > >>>>>>>> Jozef > >>>>>>>> > >>>>>>>> > >>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: > >>>>>>>> > >>>>>>>> Hi all, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> https://issues.jboss.org/browse/CDI-499 comes > > after a lot of > >>>>>> discussion about async events. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I think the solution exposed here is quite > > satisfying, yet the idea > >>>>>> to need to activate async behaviour on the observer side > > doesn?t please a lot of > >>>>>> us. It?ll be confusing for users to have to activate async > > from the firing end > >>>>>> and consuming end to see it work :-(. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I?d like to see alternative proposal to have > > this new feature as > >>>>>> user friendly as possible and keep the retro-compatibility > > aspect. We should > >>>>>> find a better solution on our next meeting on wednesday. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 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. > > > >>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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. > >>> > >>> > >> > >> _______________________________________________ > >> 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/20150210/d76cf9ea/attachment-0001.html From struberg at yahoo.de Tue Feb 10 02:53:30 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 07:53:30 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: Message-ID: <1995246191.1465726.1423554810674.JavaMail.yahoo@mail.yahoo.com> Hi Jos?! Backward compatibility is perfectly fine with both approaches. People can use BeanManager#fire() instead of the newly proposed BeanManager#fireAsync(). My point is that many people will simply not be able to use fireAsync() because as a framework developer you really need to code defensive. Without an explicit opt-in on observer side fireAsync() can basically only be used in situations where you _exactly_ know all your observers... An own @Async annotation would also be nice as it could not only be used at @Observes but also for @Event @Inject @Async @Event private Event userLoggedInEventSource; The benefit of an own @Async annotation over extending e.g. the @Event annotation is that it would be perfectly backward compatible. This code would also run on CDI-1.0 .. 1.2 containers (as all annotations which are not available on the classpath will simply be ignored by the JVM. LieGrue, strub On Tuesday, 10 February 2015, 8:41, Jos? Paumard wrote: >Mark, >It vas never been in the mind of anyone to modify the way things work currently. Keeping the backward compatibility is a prerequisite to any kind of modification or improvment added to the spec. This has already been said and written several times. >Jos? >Le 10 f?vr. 2015 07:37, "Mark Struberg" a ?crit : > >Good morning! >> >> >>Folks, please think a bit further. >> >> >>I'll give you a practical example. What should a developer do first? Eat their own dog food... >> >>Where does this apply to us? Means where do _we_ use CDI events? Right, in CDI Extensions. >> >>So ask yourself a simple question: if we like to leverage async events in CDI extensions then how could we do that? Your suggestion was to just use fireAsync instead of fire, right? >> >>Now imagine what would happen if we would do that... I'd say most real world apps would go BOOOOMMMMM and not even finish the start. Simply because most CDI extensions are not built to be executed in parallel. Just look at Extensions who collect information about classes in @Observes ProcessAnnotatedType. Most of the time they collect this in a non-concurrent Set or List >> >>private final Collection> messageBundleTypes = new HashSet>(); >> >> >>If you fire the ProcessAnnotatedType event in parallel then you will blow up. And this was just ONE example. There are tons of other CDI Extension Events which would have the same result if switched to fireAsync. >> >> >>Now think about what would happen IF we would have an @Async on the observer? >> >>All would work. Old extensions still will get triggered in the same thread, but extensions with @Async would leverage parallel behaviour. >> >> >>I hope this practical sample makes it more clear why I think that most of the time we cannot simply switch to fireAsync if there is old code around which is not under your full control. >> >> >>LieGrue, >>strub >> >> >> >> >> >> >>> On Monday, 9 February 2015, 20:56, Romain Manni-Bucau wrote: >>> > I guess 2 is not a real need - and at least not why people voted for >>> this feature. Difference between fireAsync and @Async is who decides >>> to be asynchronous. Caller (fire) should clearly be able IMO - with >>> all the warning we can put in the spec to say it should be done with >>> compatible scopes. The second one is less important for me cause you >>> can already do it with concurrency utilities (ee one or not) pretty >>> easily. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-09 20:33 GMT+01:00 Mark Struberg : >>>> Btw, did we already cover the 'fireAndForget' vs >>> 'fireAndWait' use cases? >>>> >>>> 1. fireAndForget: this is basically what you get today if you use >>> @javax.ejb.Asynchronous on an @Observer method >>>> >>>> 2.) fireAndWait: call all observers in a new thread and only return after >>> all observer methods did finish. >>>> >>>> >>>> >>>> Did we already agree on one of the 2 modi? If not, do we like to support >>> both? And if so, how to tell the CDI container which of the 2 modes to use for >>> each observer? >>>> >>>> >>>> If you answer the last question with yes then we might need some >>> annotation/additional info on the observer method anyway. And then we are back >>> on our @Async annotation on the observer method... >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau >>> wrote: >>>>> Guys I'm not sure to fully get the jira description now. Can you try >>>>> to rephrase it a bit? >>>>> >>>>> Here what I see: >>>>> >>>>> 1) fireAsync (+1) is clear >>>>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I >>>>> think this API is not usable (=user friendly) and I would just suggest >>>>> it is on by default and to remove this flag >>>>> >>>>> >>>>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No >>>>> since it is not yet used and this is surely what we want. I fully >>>>> understand all the mentionned pitfalls - but let me say @RequestScoped >>>>> is by definition as broken as this today since you can't associate >>> it >>>>> with a request for the exact same reason. What I mean is: if you >>>>> choose async then you assume it so I think we shouldn't protect the >>>>> user from pitfalls then...in particular since we can't protect him >>>>> from other as vicious issues. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand >>> : >>>>>> Mark I understand your concern, now can you understand the one we >>> discussed about the fact of having to enable async at both ends is a source of >>> confusion for end users and will give a bad perception of the spec. >>>>>> >>>>>> So could we figure something user friendly to enable async event? >>>>>> >>>>>> Antoine >>>>>> >>>>>> >>>>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg >>> a ?crit : >>>>>>> >>>>>>> But that might defeat pluggabilgity. Basically no framework can >>> use fireAsync in that case. >>>>>>> >>>>>>> Imagine a UserLoggedIn event. For most observers it is >>> perfectly fine to observe this in a new thread. But some might need to access >>> the session -> boom. Which means that all frameworks have to fall back to the >>> 'safe' fire() instead of fireAsync()... >>>>>>> >>>>>>> That will leave us half-broken as it totally defeats the usage >>> of this cool feature... >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand >>> wrote: >>>>>>>>> Mark, >>>>>>>> >>>>>>>> >>>>>>>> During last meeting we didn?t say there wasn?t use case >>> that would break >>>>>>>> existing observer, we said that since we keep the current >>> fire() method there is >>>>>>>> backward compatibility. User trying to send fireAsync() and >>> experiencing error >>>>>>>> with legacy observer will have to fall back to fire(). >>>>>>>> >>>>>>>> Antoine >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg >>> a ?crit : >>>>>>>>> >>>>>>>>> Hi Jozef, here we go! >>>>>>>>> >>>>>>>>> >>>>>>>>> 1.) accessing @RequestScoped beans in your Observer >>>>>>>>> >>>>>>>>> 2.) accessing @SessionScoped beans in your Observer >>>>>>>>> 3.) accessing/relying on any transactional behaviour. >>> This is really a >>>>>>>> boomer. Basically you break transactions that way. >>>>>>>>> >>>>>>>>> 4.) accessing @TransactionScoped beans in your Observer >>>>>>>>> >>>>>>>>> 5.) access/relying on any ThreadLocal in your Observer >>>>>>>>> 6.) accessing attached entities in your Observers (they >>> must only get >>>>>>>> accessed from a very single Thread according to the JPA >>> spec) >>>>>>>>> 7.) using an EntityManager in a parallel thread might >>> give you unexpected >>>>>>>> results. >>>>>>>>> >>>>>>>>> >>>>>>>>> There might be quite a few more. E.g. we need to >>> specify that EJBs and >>>>>>>> other EE features need to work in such a new Thread, etc >>>>>>>>> >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We should enumerate all the arguments supporting >>> async flag on an >>>>>>>> observer. So far I have only seen one: >>>>>>>>>> >>>>>>>>>> - an observer accessing @RequestScoped state would >>> no longer be able >>>>>>>>> to do so since it would be run in a worker thread >>>>>>>>>> >>>>>>>>>> I am eager to hear more arguments as this single >>> one may not be >>>>>>>>> enough to justify the observer-async-flag design >>> decision. >>>>>>>>>> >>>>>>>>>> Remember that introducing fireAsync() itself does >>> not break any >>>>>>>>> existing application because existing applications >>> are using fire(). >>>>>>>>> It's when an existing application / library is >>> modified to use >>>>>>>>> fireAsync() when the problem may occur. Such change >>> should not be >>>>>>>>> done blindly. As with any other change, an author >>> should consider >>>>>>>>> possible consequences of the change. Clearly >>> documenting the fact >>>>>>>>> that fireAsync() processing is done in a different >>> thread with a >>>>>>>>> different @RequestScoped state may be sufficient. >>>>>>>>>> >>>>>>>>>> Jozef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://issues.jboss.org/browse/CDI-499 comes >>> after a lot of >>>>>>>> discussion about async events. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think the solution exposed here is quite >>> satisfying, yet the idea >>>>>>>> to need to activate async behaviour on the observer side >>> doesn?t please a lot of >>>>>>>> us. It?ll be confusing for users to have to activate async >>> from the firing end >>>>>>>> and consuming end to see it work :-(. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I?d like to see alternative proposal to have >>> this new feature as >>>>>>>> user friendly as possible and keep the retro-compatibility >>> aspect. We should >>>>>>>> find a better solution on our next meeting on wednesday. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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. >>> >>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 struberg at yahoo.de Tue Feb 10 03:13:25 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 08:13:25 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <1995246191.1465726.1423554810674.JavaMail.yahoo@mail.yahoo.com> References: <1995246191.1465726.1423554810674.JavaMail.yahoo@mail.yahoo.com> Message-ID: <274426769.1491084.1423556005544.JavaMail.yahoo@mail.yahoo.com> Oh one more thing I found which is most probably broken or totally changes the behaviour 8.) All observers with transactionPhase != IN_PROGRESS LieGrue, strub > On Tuesday, 10 February 2015, 8:58, Mark Struberg wrote: > > Hi Jos?! > > Backward compatibility is perfectly fine with both approaches. People can use > BeanManager#fire() instead of the newly proposed BeanManager#fireAsync(). > > > My point is that many people will simply not be able to use fireAsync() because > as a framework developer you really need to code defensive. Without an explicit > opt-in on observer side fireAsync() can basically only be used in situations > where you _exactly_ know all your observers... > > An own @Async annotation would also be nice as it could not only be used at > @Observes but also for @Event > > @Inject > @Async > > @Event > > private Event userLoggedInEventSource; > > > The benefit of an own @Async annotation over extending e.g. the @Event > annotation is that it would be perfectly backward compatible. This code would > also run on CDI-1.0 .. 1.2 containers (as all annotations which are not > available on the classpath will simply be ignored by the JVM. > > LieGrue, > strub > From jharting at redhat.com Tue Feb 10 04:30:00 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 10 Feb 2015 10:30:00 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <504649759.1128801.1423476742379.JavaMail.yahoo@mail.yahoo.com> References: <03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net> <54D0892D.108@redhat.com> <504649759.1128801.1423476742379.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54D9CF98.7070903@redhat.com> Right, these usecases won't work together with async delivery. In an ideal world an event payload would contain all the state possibly needed by an observer and the payload would be documented to be fired async. In an ideal world users would not rely on any of those bullets you wrote as they would understand async. Same as you would not use of those bullets in MDB's onReceive(), @Asynchronous method or Akka actor's receive(). Or would you? Now obviously that is an ideal world far from the real one in which this is a risk. On the other hand, the "async switch on both sides" option, which you prefer, is a huge barrier to adoption. Seems that we currently have two options out of which none is a good one. On 02/09/2015 11:12 AM, Mark Struberg wrote: > Hi Jozef, here we go! > > > 1.) accessing @RequestScoped beans in your Observer > > 2.) accessing @SessionScoped beans in your Observer > 3.) accessing/relying on any transactional behaviour. This is really a boomer. Basically you break transactions that way. > > 4.) accessing @TransactionScoped beans in your Observer > > 5.) access/relying on any ThreadLocal in your Observer > 6.) accessing attached entities in your Observers (they must only get accessed from a very single Thread according to the JPA spec) > 7.) using an EntityManager in a parallel thread might give you unexpected results. > > > There might be quite a few more. E.g. we need to specify that EJBs and other EE features need to work in such a new Thread, etc > > > LieGrue, > strub > > > On Tuesday, 3 February 2015, 9:40, Jozef Hartinger wrote: > > >> >> We should enumerate all the arguments supporting async flag on an observer. So far I have only seen one: >> >> - an observer accessing @RequestScoped state would no longer be able > to do so since it would be run in a worker thread >> I am eager to hear more arguments as this single one may not be > enough to justify the observer-async-flag design decision. >> Remember that introducing fireAsync() itself does not break any > existing application because existing applications are using fire(). > It's when an existing application / library is modified to use > fireAsync() when the problem may occur. Such change should not be > done blindly. As with any other change, an author should consider > possible consequences of the change. Clearly documenting the fact > that fireAsync() processing is done in a different thread with a > different @RequestScoped state may be sufficient. >> Jozef >> >> >> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >> >> Hi all, >>> >>> >>> >>> https://issues.jboss.org/browse/CDI-499 comes after a lot of discussion about async events. >>> >>> >>> I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn?t please a lot of us. It?ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(. >>> >>> >>> I?d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday. >>> >>> >>> 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. >> _______________________________________________ >> 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 jharting at redhat.com Tue Feb 10 04:30:34 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 10 Feb 2015 10:30:34 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <274426769.1491084.1423556005544.JavaMail.yahoo@mail.yahoo.com> References: <1995246191.1465726.1423554810674.JavaMail.yahoo@mail.yahoo.com> <274426769.1491084.1423556005544.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54D9CFBA.2090301@redhat.com> Transactional observers are by definition async so they should behave the same no matter if fired with fire() or fireAsync(). On 02/10/2015 09:13 AM, Mark Struberg wrote: > Oh one more thing I found which is most probably broken or totally changes the behaviour > > 8.) All observers with transactionPhase != IN_PROGRESS > > LieGrue, > strub > > > > >> On Tuesday, 10 February 2015, 8:58, Mark Struberg wrote: >>> Hi Jos?! >> Backward compatibility is perfectly fine with both approaches. People can use >> BeanManager#fire() instead of the newly proposed BeanManager#fireAsync(). >> >> >> My point is that many people will simply not be able to use fireAsync() because >> as a framework developer you really need to code defensive. Without an explicit >> opt-in on observer side fireAsync() can basically only be used in situations >> where you _exactly_ know all your observers... >> >> An own @Async annotation would also be nice as it could not only be used at >> @Observes but also for @Event >> >> @Inject >> @Async >> >> @Event >> >> private Event userLoggedInEventSource; >> >> >> The benefit of an own @Async annotation over extending e.g. the @Event >> annotation is that it would be perfectly backward compatible. This code would >> also run on CDI-1.0 .. 1.2 containers (as all annotations which are not >> available on the classpath will simply be ignored by the JVM. >> >> LieGrue, >> strub >> > _______________________________________________ > 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 jharting at redhat.com Tue Feb 10 04:31:48 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 10 Feb 2015 10:31:48 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <923477804.1302763.1423510401344.JavaMail.yahoo@mail.yahoo.com> References: <923477804.1302763.1423510401344.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54D9D004.2000502@redhat.com> The current proposal is for fireAsync() to never wait for completion. If needed, a completion callback may be registered on the CompletableFuture/CompletionStage-like object returned from fireAsync(). http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalEvent.html#fireAsync-U- On 02/09/2015 08:33 PM, Mark Struberg wrote: > Btw, did we already cover the 'fireAndForget' vs 'fireAndWait' use cases? > > 1. fireAndForget: this is basically what you get today if you use @javax.ejb.Asynchronous on an @Observer method > > 2.) fireAndWait: call all observers in a new thread and only return after all observer methods did finish. > > > > Did we already agree on one of the 2 modi? If not, do we like to support both? And if so, how to tell the CDI container which of the 2 modes to use for each observer? > > > If you answer the last question with yes then we might need some annotation/additional info on the observer method anyway. And then we are back on our @Async annotation on the observer method... > > > LieGrue, > strub > > > On Monday, 9 February 2015, 18:43, Romain Manni-Bucau wrote: >> Guys I'm not sure to fully get the jira description now. Can you try >> to rephrase it a bit? >> >> Here what I see: >> >> 1) fireAsync (+1) is clear >> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I >> think this API is not usable (=user friendly) and I would just suggest >> it is on by default and to remove this flag >> >> >> Can it break apps? Yes as mentionned by Mark. Will it break apps? No >> since it is not yet used and this is surely what we want. I fully >> understand all the mentionned pitfalls - but let me say @RequestScoped >> is by definition as broken as this today since you can't associate it >> with a request for the exact same reason. What I mean is: if you >> choose async then you assume it so I think we shouldn't protect the >> user from pitfalls then...in particular since we can't protect him > >from other as vicious issues. >> >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand : >>> Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec. >>> >>> So could we figure something user friendly to enable async event? >>> >>> Antoine >>> >>> >>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg a ?crit : >>>> >>>> But that might defeat pluggabilgity. Basically no framework can use fireAsync in that case. >>>> >>>> Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a new thread. But some might need to access the session -> boom. Which means that all frameworks have to fall back to the 'safe' fire() instead of fireAsync()... >>>> >>>> That will leave us half-broken as it totally defeats the usage of this cool feature... >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> >>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand wrote: >>>>>> Mark, >>>>> >>>>> During last meeting we didn?t say there wasn?t use case that would break >>>>> existing observer, we said that since we keep the current fire() method there is >>>>> backward compatibility. User trying to send fireAsync() and experiencing error >>>>> with legacy observer will have to fall back to fire(). >>>>> >>>>> Antoine >>>>> >>>>> >>>>> >>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg a ?crit : >>>>>> >>>>>> Hi Jozef, here we go! >>>>>> >>>>>> >>>>>> 1.) accessing @RequestScoped beans in your Observer >>>>>> >>>>>> 2.) accessing @SessionScoped beans in your Observer >>>>>> 3.) accessing/relying on any transactional behaviour. This is really a >>>>> boomer. Basically you break transactions that way. >>>>>> 4.) accessing @TransactionScoped beans in your Observer >>>>>> >>>>>> 5.) access/relying on any ThreadLocal in your Observer >>>>>> 6.) accessing attached entities in your Observers (they must only get >>>>> accessed from a very single Thread according to the JPA spec) >>>>>> 7.) using an EntityManager in a parallel thread might give you unexpected >>>>> results. >>>>>> >>>>>> There might be quite a few more. E.g. we need to specify that EJBs and >>>>> other EE features need to work in such a new Thread, etc >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger >>>>> wrote: >>>>>> >>>>>>> >>>>>>> We should enumerate all the arguments supporting async flag on an >>>>> observer. So far I have only seen one: >>>>>>> - an observer accessing @RequestScoped state would no longer be able >>>>>> to do so since it would be run in a worker thread >>>>>>> I am eager to hear more arguments as this single one may not be >>>>>> enough to justify the observer-async-flag design decision. >>>>>>> Remember that introducing fireAsync() itself does not break any >>>>>> existing application because existing applications are using fire(). >>>>>> It's when an existing application / library is modified to use >>>>>> fireAsync() when the problem may occur. Such change should not be >>>>>> done blindly. As with any other change, an author should consider >>>>>> possible consequences of the change. Clearly documenting the fact >>>>>> that fireAsync() processing is done in a different thread with a >>>>>> different @RequestScoped state may be sufficient. >>>>>>> Jozef >>>>>>> >>>>>>> >>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: >>>>>>> >>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://issues.jboss.org/browse/CDI-499 comes after a lot of >>>>> discussion about async events. >>>>>>>> >>>>>>>> I think the solution exposed here is quite satisfying, yet the idea >>>>> to need to activate async behaviour on the observer side doesn?t please a lot of >>>>> us. It?ll be confusing for users to have to activate async from the firing end >>>>> and consuming end to see it work :-(. >>>>>>>> >>>>>>>> I?d like to see alternative proposal to have this new feature as >>>>> user friendly as possible and keep the retro-compatibility aspect. We should >>>>> find a better solution on our next meeting on wednesday. >>>>>>>> >>>>>>>> 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. >>>>>>> _______________________________________________ >>>>>>> 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. >> > _______________________________________________ > 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 struberg at yahoo.de Tue Feb 10 04:42:44 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 09:42:44 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54D9CFBA.2090301@redhat.com> References: <54D9CFBA.2090301@redhat.com> Message-ID: <343664670.1482331.1423561364657.JavaMail.yahoo@mail.yahoo.com> No they are not async in the sense that they get executed in a parallel thread. That simply won't work. Think about TransactionPhase.BEFORE_COMPLETION. There is a huge difference between 'it will get called on the same thread but I have no control _when_' and 'it will get called on a totally new thread'- For the TransactionPhase it is the first case imo. LieGrue, strub > On Tuesday, 10 February 2015, 10:30, Jozef Hartinger wrote: > >T ransactional observers are by definition async so they should behave > the same no matter if fired with fire() or fireAsync(). > > > On 02/10/2015 09:13 AM, Mark Struberg wrote: >> Oh one more thing I found which is most probably broken or totally changes > the behaviour >> >> 8.) All observers with transactionPhase != IN_PROGRESS >> >> LieGrue, >> strub >> >> >> >> >>> On Tuesday, 10 February 2015, 8:58, Mark Struberg > wrote: >>>> Hi Jos?! >>> Backward compatibility is perfectly fine with both approaches. People > can use >>> BeanManager#fire() instead of the newly proposed > BeanManager#fireAsync(). >>> >>> >>> My point is that many people will simply not be able to use fireAsync() > because >>> as a framework developer you really need to code defensive. Without an > explicit >>> opt-in on observer side fireAsync() can basically only be used in > situations >>> where you _exactly_ know all your observers... >>> >>> An No @Async annotation would also be nice as it could not only be > used at >>> @Observes but also for @Event >>> >>> @Inject >>> @Async >>> >>> @Event >>> >>> private Event userLoggedInEventSource; >>> >>> >>> The benefit of an own @Async annotation over extending e.g. the @Event >>> annotation is that it would be perfectly backward compatible. This code > would >>> also run on CDI-1.0 .. 1.2 containers (as all annotations which are not >>> available on the classpath will simply be ignored by the JVM. >>> >>> LieGrue, >>> strub >>> >> _______________________________________________ >> 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 jharting at redhat.com Tue Feb 10 04:50:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 10 Feb 2015 10:50:47 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <343664670.1482331.1423561364657.JavaMail.yahoo@mail.yahoo.com> References: <54D9CFBA.2090301@redhat.com> <343664670.1482331.1423561364657.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54D9D477.1080901@redhat.com> Async is not about a parallel thread. It is about fire() not waiting until an observer finishes. Transactional observers are async already. No need to make things more complicated by involving a "parallel thread". On 02/10/2015 10:42 AM, Mark Struberg wrote: > No they are not async in the sense that they get executed in a parallel thread. That simply won't work. Think about TransactionPhase.BEFORE_COMPLETION. > There is a huge difference between 'it will get called on the same thread but I have no control _when_' and 'it will get called on a totally new thread'- > > For the TransactionPhase it is the first case imo. > > LieGrue, > strub > > > > >> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger wrote: >>> T ransactional observers are by definition async so they should behave >> the same no matter if fired with fire() or fireAsync(). >> >> >> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>> Oh one more thing I found which is most probably broken or totally changes >> the behaviour >>> 8.) All observers with transactionPhase != IN_PROGRESS >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >> wrote: >>>>> Hi Jos?! >>>> Backward compatibility is perfectly fine with both approaches. People >> can use >>>> BeanManager#fire() instead of the newly proposed >> BeanManager#fireAsync(). >>>> >>>> My point is that many people will simply not be able to use fireAsync() >> because >>>> as a framework developer you really need to code defensive. Without an >> explicit >>>> opt-in on observer side fireAsync() can basically only be used in >> situations >>>> where you _exactly_ know all your observers... >>>> >>>> An No @Async annotation would also be nice as it could not only be >> used at >>>> @Observes but also for @Event >>>> >>>> @Inject >>>> @Async >>>> >>>> @Event >>>> >>>> private Event userLoggedInEventSource; >>>> >>>> >>>> The benefit of an own @Async annotation over extending e.g. the @Event >>>> annotation is that it would be perfectly backward compatible. This code >> would >>>> also run on CDI-1.0 .. 1.2 containers (as all annotations which are not >>>> available on the classpath will simply be ignored by the JVM. >>>> >>>> LieGrue, >>>> strub >>>> >>> _______________________________________________ >>> 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 struberg at yahoo.de Tue Feb 10 04:53:05 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 09:53:05 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54D9D477.1080901@redhat.com> References: <54D9D477.1080901@redhat.com> Message-ID: <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete? Wonder how that would work... LieGrue, strub > On Tuesday, 10 February 2015, 10:50, Jozef Hartinger wrote: > > Async is not about a parallel thread. It is about fire() not waiting > until an observer finishes. Transactional observers are async already. > No need to make things more complicated by involving a "parallel > thread". > > > On 02/10/2015 10:42 AM, Mark Struberg wrote: >> No they are not async in the sense that they get executed in a parallel > thread. That simply won't work. Think about > TransactionPhase.BEFORE_COMPLETION. >> There is a huge difference between 'it will get called on the same > thread but I have no control _when_' and 'it will get called on a > totally new thread'- >> >> For the TransactionPhase it is the first case imo. >> >> LieGrue, >> strub >> >> >> >> >>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger > wrote: >>>> T ransactional observers are by definition async so they should > behave >>> the same no matter if fired with fire() or fireAsync(). >>> >>> >>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>> Oh one more thing I found which is most probably broken or > totally changes >>> the behaviour >>>> 8.) All observers with transactionPhase != IN_PROGRESS >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >>> wrote: >>>>>> Hi Jos?! >>>>> Backward compatibility is perfectly fine with both > approaches. People >>> can use >>>>> BeanManager#fire() instead of the newly proposed >>> BeanManager#fireAsync(). >>>>> >>>>> My point is that many people will simply not be able to use > fireAsync() >>> because >>>>> as a framework developer you really need to code defensive. > Without an >>> explicit >>>>> opt-in on observer side fireAsync() can basically only be > used in >>> situations >>>>> where you _exactly_ know all your observers... >>>>> >>>>> An No @Async annotation would also be nice as it could not > only be >>> used at >>>>> @Observes but also for @Event >>>>> >>>>> @Inject >>>>> @Async >>>>> >>>>> @Event >>>>> >>>>> private Event userLoggedInEventSource; >>>>> >>>>> >>>>> The benefit of an own @Async annotation over extending e.g. > the @Event >>>>> annotation is that it would be perfectly backward compatible. > This code >>> would >>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations > which are not >>>>> available on the classpath will simply be ignored by the JVM. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>> _______________________________________________ >>>> 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 Tue Feb 10 05:33:08 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 10 Feb 2015 11:33:08 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> References: <54D9D477.1080901@redhat.com> <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> Message-ID: <9D1F4DCE-C48C-4E8C-A25A-45946346EF61@sabot-durand.net> Guys, We surely have more to think about these subject. What I propose is to write today a document exposing all the question regarding async events and we?ll try to give answer and agreed at the next meeting tomorrow (you'll be able prepare you answer and even contribute them to the doc tonight or write question I would have missed) and the week after if necessary. I?ll wrote this doc starting from CDI-499 and remarks in this thread. The idea is to have something simple for users yet with minimal or no limitation for advanced users (framework developer, side). But remember this will work if EVERYONE participate to the meeting or to the discussion. We don?t have an infinite time to produce CDI 2.0. I agree that it is very important to do it well, but returning to points already discussed (even with the best reason) impact our features list and is a lost of time for everyone. So try to keep the rhythm or raise hand when a subject is important to you and you don?t have time follow : we can switch to another topic waiting for your feedback. On my side, I?ll try to give your more visibility on meeting agenda and will post link to the minutes here to avoid this ?going-back" effect. regards, Antoine > Le 10 f?vr. 2015 ? 10:53, Mark Struberg a ?crit : > > purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete? > > Wonder how that would work... > > LieGrue, > strub > > > > >> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger wrote: >>> Async is not about a parallel thread. It is about fire() not waiting >> until an observer finishes. Transactional observers are async already. >> No need to make things more complicated by involving a "parallel >> thread". >> >> >> On 02/10/2015 10:42 AM, Mark Struberg wrote: >>> No they are not async in the sense that they get executed in a parallel >> thread. That simply won't work. Think about >> TransactionPhase.BEFORE_COMPLETION. >>> There is a huge difference between 'it will get called on the same >> thread but I have no control _when_' and 'it will get called on a >> totally new thread'- >>> >>> For the TransactionPhase it is the first case imo. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger >> wrote: >>>>> T ransactional observers are by definition async so they should >> behave >>>> the same no matter if fired with fire() or fireAsync(). >>>> >>>> >>>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>>> Oh one more thing I found which is most probably broken or >> totally changes >>>> the behaviour >>>>> 8.) All observers with transactionPhase != IN_PROGRESS >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >>>> wrote: >>>>>>> Hi Jos?! >>>>>> Backward compatibility is perfectly fine with both >> approaches. People >>>> can use >>>>>> BeanManager#fire() instead of the newly proposed >>>> BeanManager#fireAsync(). >>>>>> >>>>>> My point is that many people will simply not be able to use >> fireAsync() >>>> because >>>>>> as a framework developer you really need to code defensive. >> Without an >>>> explicit >>>>>> opt-in on observer side fireAsync() can basically only be >> used in >>>> situations >>>>>> where you _exactly_ know all your observers... >>>>>> >>>>>> An No @Async annotation would also be nice as it could not >> only be >>>> used at >>>>>> @Observes but also for @Event >>>>>> >>>>>> @Inject >>>>>> @Async >>>>>> >>>>>> @Event >>>>>> >>>>>> private Event userLoggedInEventSource; >>>>>> >>>>>> >>>>>> The benefit of an own @Async annotation over extending e.g. >> the @Event >>>>>> annotation is that it would be perfectly backward compatible. >> This code >>>> would >>>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations >> which are not >>>>>> available on the classpath will simply be ignored by the JVM. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>> _______________________________________________ >>>>> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/b9d8a2c2/attachment.bin From jharting at redhat.com Tue Feb 10 05:40:02 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 10 Feb 2015 11:40:02 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> References: <54D9D477.1080901@redhat.com> <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54D9E002.7000008@redhat.com> The way transactional observers are defined is that the observer method is not called right away within the fire() call but instead is scheduled to be executed in the corresponding transaction phase (e.g. using JTA's Synchronization). This allows the fire() call to exit without waiting for the observer to complete. Therefore, the transactional observer notification is asynchronous. This has been the case since CDI 1.0 and OWB should implement it that way too! On 02/10/2015 10:53 AM, Mark Struberg wrote: > purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete? > > Wonder how that would work... > > LieGrue, > strub > > > > >> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger wrote: >>> Async is not about a parallel thread. It is about fire() not waiting >> until an observer finishes. Transactional observers are async already. >> No need to make things more complicated by involving a "parallel >> thread". >> >> >> On 02/10/2015 10:42 AM, Mark Struberg wrote: >>> No they are not async in the sense that they get executed in a parallel >> thread. That simply won't work. Think about >> TransactionPhase.BEFORE_COMPLETION. >>> There is a huge difference between 'it will get called on the same >> thread but I have no control _when_' and 'it will get called on a >> totally new thread'- >>> For the TransactionPhase it is the first case imo. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger >> wrote: >>>>> T ransactional observers are by definition async so they should >> behave >>>> the same no matter if fired with fire() or fireAsync(). >>>> >>>> >>>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>>> Oh one more thing I found which is most probably broken or >> totally changes >>>> the behaviour >>>>> 8.) All observers with transactionPhase != IN_PROGRESS >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >>>> wrote: >>>>>>> Hi Jos?! >>>>>> Backward compatibility is perfectly fine with both >> approaches. People >>>> can use >>>>>> BeanManager#fire() instead of the newly proposed >>>> BeanManager#fireAsync(). >>>>>> My point is that many people will simply not be able to use >> fireAsync() >>>> because >>>>>> as a framework developer you really need to code defensive. >> Without an >>>> explicit >>>>>> opt-in on observer side fireAsync() can basically only be >> used in >>>> situations >>>>>> where you _exactly_ know all your observers... >>>>>> >>>>>> An No @Async annotation would also be nice as it could not >> only be >>>> used at >>>>>> @Observes but also for @Event >>>>>> >>>>>> @Inject >>>>>> @Async >>>>>> >>>>>> @Event >>>>>> >>>>>> private Event userLoggedInEventSource; >>>>>> >>>>>> >>>>>> The benefit of an own @Async annotation over extending e.g. >> the @Event >>>>>> annotation is that it would be perfectly backward compatible. >> This code >>>> would >>>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations >> which are not >>>>>> available on the classpath will simply be ignored by the JVM. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>> _______________________________________________ >>>>> 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 Tue Feb 10 05:51:08 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 10 Feb 2015 11:51:08 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54D9E002.7000008@redhat.com> References: <54D9D477.1080901@redhat.com> <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> <54D9E002.7000008@redhat.com> Message-ID: <7DD43797-2E4B-469D-A3A7-048C253A2FF7@sabot-durand.net> Jozef, One question. So today we have an async behaviour with transactional observer. What about event payload modification in these observer ? Antoine Sabot-Durand > Le 10 f?vr. 2015 ? 11:40, Jozef Hartinger a ?crit : > > The way transactional observers are defined is that the observer method > is not called right away within the fire() call but instead is scheduled > to be executed in the corresponding transaction phase (e.g. using JTA's > Synchronization). This allows the fire() call to exit without waiting > for the observer to complete. Therefore, the transactional observer > notification is asynchronous. This has been the case since CDI 1.0 and > OWB should implement it that way too! > >> On 02/10/2015 10:53 AM, Mark Struberg wrote: >> purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete? >> >> Wonder how that would work... >> >> LieGrue, >> strub >> >> >> >> >>>> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger wrote: >>>> Async is not about a parallel thread. It is about fire() not waiting >>> until an observer finishes. Transactional observers are async already. >>> No need to make things more complicated by involving a "parallel >>> thread". >>> >>> >>>> On 02/10/2015 10:42 AM, Mark Struberg wrote: >>>> No they are not async in the sense that they get executed in a parallel >>> thread. That simply won't work. Think about >>> TransactionPhase.BEFORE_COMPLETION. >>>> There is a huge difference between 'it will get called on the same >>> thread but I have no control _when_' and 'it will get called on a >>> totally new thread'- >>>> For the TransactionPhase it is the first case imo. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger >>> wrote: >>>>>> T ransactional observers are by definition async so they should >>> behave >>>>> the same no matter if fired with fire() or fireAsync(). >>>>> >>>>> >>>>>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>>>> Oh one more thing I found which is most probably broken or >>> totally changes >>>>> the behaviour >>>>>> 8.) All observers with transactionPhase != IN_PROGRESS >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >>>>> wrote: >>>>>>>> Hi Jos?! >>>>>>> Backward compatibility is perfectly fine with both >>> approaches. People >>>>> can use >>>>>>> BeanManager#fire() instead of the newly proposed >>>>> BeanManager#fireAsync(). >>>>>>> My point is that many people will simply not be able to use >>> fireAsync() >>>>> because >>>>>>> as a framework developer you really need to code defensive. >>> Without an >>>>> explicit >>>>>>> opt-in on observer side fireAsync() can basically only be >>> used in >>>>> situations >>>>>>> where you _exactly_ know all your observers... >>>>>>> >>>>>>> An No @Async annotation would also be nice as it could not >>> only be >>>>> used at >>>>>>> @Observes but also for @Event >>>>>>> >>>>>>> @Inject >>>>>>> @Async >>>>>>> >>>>>>> @Event >>>>>>> >>>>>>> private Event userLoggedInEventSource; >>>>>>> >>>>>>> >>>>>>> The benefit of an own @Async annotation over extending e.g. >>> the @Event >>>>>>> annotation is that it would be perfectly backward compatible. >>> This code >>>>> would >>>>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations >>> which are not >>>>>>> available on the classpath will simply be ignored by the JVM. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 werner.keil at gmail.com Tue Feb 10 06:12:03 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 10 Feb 2015 12:12:03 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 Message-ID: Mark, What do you mean by @Event? CDI contains the Event interface, no annotation. Are you proposing a new annotation or was it a typo? So did you mean @Async private Event userLoggedInEventSource; below? Werner On Tue, Feb 10, 2015 at 10:31 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: Async events. We need ideas to improve CDI-499 (Mark Struberg) > 2. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg) > 3. Re: Async events. We need ideas to improve CDI-499 > (Jozef Hartinger) > 4. Re: Async events. We need ideas to improve CDI-499 > (Jozef Hartinger) > 5. Re: Async events. We need ideas to improve CDI-499 > (Jozef Hartinger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 10 Feb 2015 07:53:30 +0000 (UTC) > From: Mark Struberg > Subject: Re: [cdi-dev] Async events. We need ideas to improve CDI-499 > To: Jos? Paumard > Cc: cdi-dev > Message-ID: > <1995246191.1465726.1423554810674.JavaMail.yahoo at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Jos?! > > Backward compatibility is perfectly fine with both approaches. People can > use BeanManager#fire() instead of the newly proposed > BeanManager#fireAsync(). > > > My point is that many people will simply not be able to use fireAsync() > because as a framework developer you really need to code defensive. Without > an explicit opt-in on observer side fireAsync() can basically only be used > in situations where you _exactly_ know all your observers... > > An own @Async annotation would also be nice as it could not only be used > at @Observes but also for @Event > > @Inject > @Async > > @Event > > private Event userLoggedInEventSource; > > > The benefit of an own @Async annotation over extending e.g. the @Event > annotation is that it would be perfectly backward compatible. This code > would also run on CDI-1.0 .. 1.2 containers (as all annotations which are > not available on the classpath will simply be ignored by the JVM. > > LieGrue, > strub > > > > On Tuesday, 10 February 2015, 8:41, Jos? Paumard > wrote: > >Mark, > >It vas never been in the mind of anyone to modify the way things work > currently. Keeping the backward compatibility is a prerequisite to any kind > of modification or improvment added to the spec. This has already been said > and written several times. > >Jos? > >Le 10 f?vr. 2015 07:37, "Mark Struberg" a ?crit : > > > >Good morning! > >> > >> > >>Folks, please think a bit further. > >> > >> > >>I'll give you a practical example. What should a developer do first? Eat > their own dog food... > >> > >>Where does this apply to us? Means where do _we_ use CDI events? Right, > in CDI Extensions. > >> > >>So ask yourself a simple question: if we like to leverage async events > in CDI extensions then how could we do that? Your suggestion was to just > use fireAsync instead of fire, right? > >> > >>Now imagine what would happen if we would do that... I'd say most real > world apps would go BOOOOMMMMM and not even finish the start. Simply > because most CDI extensions are not built to be executed in parallel. Just > look at Extensions who collect information about classes in @Observes > ProcessAnnotatedType. Most of the time they collect this in a > non-concurrent Set or List > >> > >>private final Collection> messageBundleTypes = new > HashSet>(); > >> > >> > >>If you fire the ProcessAnnotatedType event in parallel then you will > blow up. And this was just ONE example. There are tons of other CDI > Extension Events which would have the same result if switched to fireAsync. > >> > >> > >>Now think about what would happen IF we would have an @Async on the > observer? > >> > >>All would work. Old extensions still will get triggered in the same > thread, but extensions with @Async would leverage parallel behaviour. > >> > >> > >>I hope this practical sample makes it more clear why I think that most > of the time we cannot simply switch to fireAsync if there is old code > around which is not under your full control. > >> > >> > >>LieGrue, > >>strub > >> > >> > >> > >> > >> > >> > >>> On Monday, 9 February 2015, 20:56, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>> > I guess 2 is not a real need - and at least not why people voted for > >>> this feature. Difference between fireAsync and @Async is who decides > >>> to be asynchronous. Caller (fire) should clearly be able IMO - with > >>> all the warning we can put in the spec to say it should be done with > >>> compatible scopes. The second one is less important for me cause you > >>> can already do it with concurrency utilities (ee one or not) pretty > >>> easily. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-09 20:33 GMT+01:00 Mark Struberg : > >>>> Btw, did we already cover the 'fireAndForget' vs > >>> 'fireAndWait' use cases? > >>>> > >>>> 1. fireAndForget: this is basically what you get today if you use > >>> @javax.ejb.Asynchronous on an @Observer method > >>>> > >>>> 2.) fireAndWait: call all observers in a new thread and only return > after > >>> all observer methods did finish. > >>>> > >>>> > >>>> > >>>> Did we already agree on one of the 2 modi? If not, do we like to > support > >>> both? And if so, how to tell the CDI container which of the 2 modes to > use for > >>> each observer? > >>>> > >>>> > >>>> If you answer the last question with yes then we might need some > >>> annotation/additional info on the observer method anyway. And then we > are back > >>> on our @Async annotation on the observer method... > >>>> > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau > >>> wrote: > >>>>> Guys I'm not sure to fully get the jira description now. Can you try > >>>>> to rephrase it a bit? > >>>>> > >>>>> Here what I see: > >>>>> > >>>>> 1) fireAsync (+1) is clear > >>>>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I > >>>>> think this API is not usable (=user friendly) and I would just > suggest > >>>>> it is on by default and to remove this flag > >>>>> > >>>>> > >>>>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No > >>>>> since it is not yet used and this is surely what we want. I fully > >>>>> understand all the mentionned pitfalls - but let me say > @RequestScoped > >>>>> is by definition as broken as this today since you can't associate > >>> it > >>>>> with a request for the exact same reason. What I mean is: if you > >>>>> choose async then you assume it so I think we shouldn't protect the > >>>>> user from pitfalls then...in particular since we can't protect him > >>>>> from other as vicious issues. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> @rmannibucau > >>>>> http://www.tomitribe.com > >>>>> http://rmannibucau.wordpress.com > >>>>> https://github.com/rmannibucau > >>>>> > >>>>> > >>>>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand > >>> : > >>>>>> Mark I understand your concern, now can you understand the one we > >>> discussed about the fact of having to enable async at both ends is a > source of > >>> confusion for end users and will give a bad perception of the spec. > >>>>>> > >>>>>> So could we figure something user friendly to enable async event? > >>>>>> > >>>>>> Antoine > >>>>>> > >>>>>> > >>>>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg > >>> a ?crit : > >>>>>>> > >>>>>>> But that might defeat pluggabilgity. Basically no framework can > >>> use fireAsync in that case. > >>>>>>> > >>>>>>> Imagine a UserLoggedIn event. For most observers it is > >>> perfectly fine to observe this in a new thread. But some might need to > access > >>> the session -> boom. Which means that all frameworks have to fall back > to the > >>> 'safe' fire() instead of fireAsync()... > >>>>>>> > >>>>>>> That will leave us half-broken as it totally defeats the usage > >>> of this cool feature... > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand > >>> wrote: > >>>>>>>>> Mark, > >>>>>>>> > >>>>>>>> > >>>>>>>> During last meeting we didn?t say there wasn?t use case > >>> that would break > >>>>>>>> existing observer, we said that since we keep the current > >>> fire() method there is > >>>>>>>> backward compatibility. User trying to send fireAsync() and > >>> experiencing error > >>>>>>>> with legacy observer will have to fall back to fire(). > >>>>>>>> > >>>>>>>> Antoine > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg > >>> a ?crit : > >>>>>>>>> > >>>>>>>>> Hi Jozef, here we go! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 1.) accessing @RequestScoped beans in your Observer > >>>>>>>>> > >>>>>>>>> 2.) accessing @SessionScoped beans in your Observer > >>>>>>>>> 3.) accessing/relying on any transactional behaviour. > >>> This is really a > >>>>>>>> boomer. Basically you break transactions that way. > >>>>>>>>> > >>>>>>>>> 4.) accessing @TransactionScoped beans in your Observer > >>>>>>>>> > >>>>>>>>> 5.) access/relying on any ThreadLocal in your Observer > >>>>>>>>> 6.) accessing attached entities in your Observers (they > >>> must only get > >>>>>>>> accessed from a very single Thread according to the JPA > >>> spec) > >>>>>>>>> 7.) using an EntityManager in a parallel thread might > >>> give you unexpected > >>>>>>>> results. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> There might be quite a few more. E.g. we need to > >>> specify that EJBs and > >>>>>>>> other EE features need to work in such a new Thread, etc > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> LieGrue, > >>>>>>>>> strub > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> We should enumerate all the arguments supporting > >>> async flag on an > >>>>>>>> observer. So far I have only seen one: > >>>>>>>>>> > >>>>>>>>>> - an observer accessing @RequestScoped state would > >>> no longer be able > >>>>>>>>> to do so since it would be run in a worker thread > >>>>>>>>>> > >>>>>>>>>> I am eager to hear more arguments as this single > >>> one may not be > >>>>>>>>> enough to justify the observer-async-flag design > >>> decision. > >>>>>>>>>> > >>>>>>>>>> Remember that introducing fireAsync() itself does > >>> not break any > >>>>>>>>> existing application because existing applications > >>> are using fire(). > >>>>>>>>> It's when an existing application / library is > >>> modified to use > >>>>>>>>> fireAsync() when the problem may occur. Such change > >>> should not be > >>>>>>>>> done blindly. As with any other change, an author > >>> should consider > >>>>>>>>> possible consequences of the change. Clearly > >>> documenting the fact > >>>>>>>>> that fireAsync() processing is done in a different > >>> thread with a > >>>>>>>>> different @RequestScoped state may be sufficient. > >>>>>>>>>> > >>>>>>>>>> Jozef > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote: > >>>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> https://issues.jboss.org/browse/CDI-499 comes > >>> after a lot of > >>>>>>>> discussion about async events. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I think the solution exposed here is quite > >>> satisfying, yet the idea > >>>>>>>> to need to activate async behaviour on the observer side > >>> doesn?t please a lot of > >>>>>>>> us. It?ll be confusing for users to have to activate async > >>> from the firing end > >>>>>>>> and consuming end to see it work :-(. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I?d like to see alternative proposal to have > >>> this new feature as > >>>>>>>> user friendly as possible and keep the retro-compatibility > >>> aspect. We should > >>>>>>>> find a better solution on our next meeting on wednesday. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 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. > >>> > >>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> 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. > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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. > > > > > > _______________________________________________ > 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 51, Issue 21 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/7e284175/attachment-0001.html From struberg at yahoo.de Tue Feb 10 06:38:39 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 10 Feb 2015 11:38:39 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: Message-ID: <1966359205.1530238.1423568319502.JavaMail.yahoo@mail.yahoo.com> yes the @Event was superfluous. LieGrue, strub On Tuesday, 10 February 2015, 12:13, Werner Keil wrote: > > >Mark, > > >What do you mean by @Event? > > From issues at jboss.org Tue Feb 10 11:58:48 2015 From: issues at jboss.org (Abhishek Gupta (JIRA)) Date: Tue, 10 Feb 2015 11:58:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-506) '10.4.4. Conditional observer methods' - specifies incorrect Element name for @Observes annotation In-Reply-To: References: Message-ID: Abhishek Gupta created CDI-506: ---------------------------------- Summary: '10.4.4. Conditional observer methods' - specifies incorrect Element name for @Observes annotation Key: CDI-506 URL: https://issues.jboss.org/browse/CDI-506 Project: CDI Specification Issues Issue Type: Bug Environment: --NA-- (Documentation issue) Reporter: Abhishek Gupta Section 10.4.4. Conditional observer methods' - specifies 'receive' as the element name for the @Observes annotation. The correct element should be 'notifyObserver' as per Javadocs http://bit.ly/16PfyhD public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From john.d.ament at gmail.com Tue Feb 10 12:58:51 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 10 Feb 2015 17:58:51 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) Message-ID: All, I have the updated API here, and wanted to solicit any final feedback before updating the google doc and spec pages. https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c Let me know your thoughts. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/1f8ee45b/attachment.html From antonio.goncalves at gmail.com Wed Feb 11 03:47:43 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Wed, 11 Feb 2015 09:47:43 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <1966359205.1530238.1423568319502.JavaMail.yahoo@mail.yahoo.com> References: <1966359205.1530238.1423568319502.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi all, Just bumped into that : https://github.com/jsr107/jsr107spec/issues/307#issuecomment-73816562 The JCache expert group is thinking of adding async methods to the cache. Antonio On Tue, Feb 10, 2015 at 12:38 PM, Mark Struberg wrote: > yes the @Event was superfluous. > > LieGrue, > strub > > > > > On Tuesday, 10 February 2015, 12:13, Werner Keil > wrote: > > > > > > > >Mark, > > > > > >What do you mean by @Event? > > > > > _______________________________________________ > 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/20150211/c9b3e43d/attachment.html From jharting at redhat.com Wed Feb 11 03:58:34 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 11 Feb 2015 09:58:34 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <7DD43797-2E4B-469D-A3A7-048C253A2FF7@sabot-durand.net> References: <54D9D477.1080901@redhat.com> <1294333034.1510910.1423561985922.JavaMail.yahoo@mail.yahoo.com> <54D9E002.7000008@redhat.com> <7DD43797-2E4B-469D-A3A7-048C253A2FF7@sabot-durand.net> Message-ID: <54DB19BA.60608@redhat.com> Usually the observers are called from within the same thread as fire(). It may however not be the case always thus relying on modification of non-thread-safe payload is probably a bad idea. On 02/10/2015 11:51 AM, Antoine Sabot-Durand wrote: > Jozef, > > One question. So today we have an async behaviour with transactional observer. What about event payload modification in these observer ? > > Antoine Sabot-Durand > > >> Le 10 f?vr. 2015 ? 11:40, Jozef Hartinger a ?crit : >> >> The way transactional observers are defined is that the observer method >> is not called right away within the fire() call but instead is scheduled >> to be executed in the corresponding transaction phase (e.g. using JTA's >> Synchronization). This allows the fire() call to exit without waiting >> for the observer to complete. Therefore, the transactional observer >> notification is asynchronous. This has been the case since CDI 1.0 and >> OWB should implement it that way too! >> >>> On 02/10/2015 10:53 AM, Mark Struberg wrote: >>> purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete? >>> >>> Wonder how that would work... >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>>> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger wrote: >>>>> Async is not about a parallel thread. It is about fire() not waiting >>>> until an observer finishes. Transactional observers are async already. >>>> No need to make things more complicated by involving a "parallel >>>> thread". >>>> >>>> >>>>> On 02/10/2015 10:42 AM, Mark Struberg wrote: >>>>> No they are not async in the sense that they get executed in a parallel >>>> thread. That simply won't work. Think about >>>> TransactionPhase.BEFORE_COMPLETION. >>>>> There is a huge difference between 'it will get called on the same >>>> thread but I have no control _when_' and 'it will get called on a >>>> totally new thread'- >>>>> For the TransactionPhase it is the first case imo. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger >>>> wrote: >>>>>>> T ransactional observers are by definition async so they should >>>> behave >>>>>> the same no matter if fired with fire() or fireAsync(). >>>>>> >>>>>> >>>>>>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>>>>> Oh one more thing I found which is most probably broken or >>>> totally changes >>>>>> the behaviour >>>>>>> 8.) All observers with transactionPhase != IN_PROGRESS >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg >>>>>> wrote: >>>>>>>>> Hi Jos?! >>>>>>>> Backward compatibility is perfectly fine with both >>>> approaches. People >>>>>> can use >>>>>>>> BeanManager#fire() instead of the newly proposed >>>>>> BeanManager#fireAsync(). >>>>>>>> My point is that many people will simply not be able to use >>>> fireAsync() >>>>>> because >>>>>>>> as a framework developer you really need to code defensive. >>>> Without an >>>>>> explicit >>>>>>>> opt-in on observer side fireAsync() can basically only be >>>> used in >>>>>> situations >>>>>>>> where you _exactly_ know all your observers... >>>>>>>> >>>>>>>> An No @Async annotation would also be nice as it could not >>>> only be >>>>>> used at >>>>>>>> @Observes but also for @Event >>>>>>>> >>>>>>>> @Inject >>>>>>>> @Async >>>>>>>> >>>>>>>> @Event >>>>>>>> >>>>>>>> private Event userLoggedInEventSource; >>>>>>>> >>>>>>>> >>>>>>>> The benefit of an own @Async annotation over extending e.g. >>>> the @Event >>>>>>>> annotation is that it would be perfectly backward compatible. >>>> This code >>>>>> would >>>>>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations >>>> which are not >>>>>>>> available on the classpath will simply be ignored by the JVM. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 jharting at redhat.com Wed Feb 11 04:21:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 11 Feb 2015 10:21:47 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: <54DB1F2B.1020609@redhat.com> Hi John, some thoughts: - instead of using BeanManager it makes more sense to me to return a CDI instance, which is a more user-friendly API (and it also exposes access to BeanManager) - is there a usecase for arbitrary keys of the "params" map or is Map sufficient? - if we could move the shutdown() method from CDIContainer to the actual container handle that we obtain from initialize(), that would look more object-oriented - what exactly is initialize() supposed to do? Is it supposed to start scanning the entire classpath for CDI beans? That could be a problem especially with spring-boot-like fat jars. I think we need an API to tell the container which classes / packages to consider. Something like Guice's binding API perhaps? - the proposal makes me wonder whether retrofitting this functionality to the CDI class wouldn't be a better option. It could look like: CDI container = CDI.initialize(); container.select(Foo.class).get(); container.shutdown(); compare it to: CDIContainer container = CDIContainerLoader. getCDIContainer(); BeanManager manager = container.initialize(); manager.getBeans(...); container.shutdown(manager); On 02/10/2015 06:58 PM, John D. Ament wrote: > All, > > I have the updated API here, and wanted to solicit any final feedback > before updating the google doc and spec pages. > > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > > Let me know your thoughts. > > Thanks, > > John > > > _______________________________________________ > 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/20150211/b708e37b/attachment.html From werner.keil at gmail.com Wed Feb 11 04:30:48 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 11 Feb 2015 10:30:48 +0100 Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: References: <1966359205.1530238.1423568319502.JavaMail.yahoo@mail.yahoo.com> Message-ID: I saw, weird they play with these things before getting Transaction Support right;-) Werner On Wed, Feb 11, 2015 at 9:47 AM, Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > Hi all, > > Just bumped into that : > https://github.com/jsr107/jsr107spec/issues/307#issuecomment-73816562 > > The JCache expert group is thinking of adding async methods to the cache. > > Antonio > > On Tue, Feb 10, 2015 at 12:38 PM, Mark Struberg wrote: > >> yes the @Event was superfluous. >> >> LieGrue, >> strub >> >> >> >> >> On Tuesday, 10 February 2015, 12:13, Werner Keil >> wrote: >> >> >> > >> > >> >Mark, >> > >> > >> >What do you mean by @Event? >> > >> > >> _______________________________________________ >> 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/20150211/7d75ee59/attachment-0001.html From struberg at yahoo.de Wed Feb 11 04:32:30 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 11 Feb 2015 09:32:30 +0000 (UTC) Subject: [cdi-dev] Async events. We need ideas to improve CDI-499 In-Reply-To: <54DB19BA.60608@redhat.com> References: <54DB19BA.60608@redhat.com> Message-ID: <1069575254.1869316.1423647150830.JavaMail.yahoo@mail.yahoo.com> Not quite sure about this. Indeed CDI doesn't specify anything in this regard. But the JPA and JTA specs clearly do specify that their handling need to be defined on the same thread. So it's kind of implicitly defined by those specs I'd say. LieGrue, strub > On Wednesday, 11 February 2015, 9:59, Jozef Hartinger wrote: > > Usually the observers are called from within the same thread as fire(). > It may however not be the case always thus relying on modification of > non-thread-safe payload is probably a bad idea. > > > On 02/10/2015 11:51 AM, Antoine Sabot-Durand wrote: >> Jozef, >> >> One question. So today we have an async behaviour with transactional > observer. What about event payload modification in these observer ? >> >> Antoine Sabot-Durand >> >> >>> Le 10 f?vr. 2015 ? 11:40, Jozef Hartinger a > ?crit : >>> >>> The way transactional observers are defined is that the observer method >>> is not called right away within the fire() call but instead is > scheduled >>> to be executed in the corresponding transaction phase (e.g. using > JTA's >>> Synchronization). This allows the fire() call to exit without waiting >>> for the observer to complete. Therefore, the transactional observer >>> notification is asynchronous. This has been the case since CDI 1.0 and >>> OWB should implement it that way too! >>> >>>> On 02/10/2015 10:53 AM, Mark Struberg wrote: >>>> purely technically: How do you manage to not spawn a new thread if > you don't like to wait for the task to complete? >>>> >>>> Wonder how that would work... >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>>> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger > wrote: >>>>>> Async is not about a parallel thread. It is about fire() > not waiting >>>>> until an observer finishes. Transactional observers are async > already. >>>>> No need to make things more complicated by involving a > "parallel >>>>> thread". >>>>> >>>>> >>>>>> On 02/10/2015 10:42 AM, Mark Struberg wrote: >>>>>> No they are not async in the sense that they get executed > in a parallel >>>>> thread. That simply won't work. Think about >>>>> TransactionPhase.BEFORE_COMPLETION. >>>>>> There is a huge difference between 'it will get > called on the same >>>>> thread but I have no control _when_' and 'it will get > called on a >>>>> totally new thread'- >>>>>> For the TransactionPhase it is the first case imo. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger >>>>> wrote: >>>>>>>> T ransactional observers are by definition async > so they should >>>>> behave >>>>>>> the same no matter if fired with fire() or > fireAsync(). >>>>>>> >>>>>>> >>>>>>>> On 02/10/2015 09:13 AM, Mark Struberg wrote: >>>>>>>> Oh one more thing I found which is most > probably broken or >>>>> totally changes >>>>>>> the behaviour >>>>>>>> 8.) All observers with transactionPhase != > IN_PROGRESS >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Tuesday, 10 February 2015, 8:58, Mark > Struberg >>>>>>> wrote: >>>>>>>>>> Hi Jos?! >>>>>>>>> Backward compatibility is perfectly fine > with both >>>>> approaches. People >>>>>>> can use >>>>>>>>> BeanManager#fire() instead of the newly > proposed >>>>>>> BeanManager#fireAsync(). >>>>>>>>> My point is that many people will simply > not be able to use >>>>> fireAsync() >>>>>>> because >>>>>>>>> as a framework developer you really need to > code defensive. >>>>> Without an >>>>>>> explicit >>>>>>>>> opt-in on observer side fireAsync() can > basically only be >>>>> used in >>>>>>> situations >>>>>>>>> where you _exactly_ know all your > observers... >>>>>>>>> >>>>>>>>> An No @Async annotation would also be nice > as it could not >>>>> only be >>>>>>> used at >>>>>>>>> @Observes but also for @Event >>>>>>>>> >>>>>>>>> @Inject >>>>>>>>> @Async >>>>>>>>> >>>>>>>>> @Event >>>>>>>>> >>>>>>>>> private Event > userLoggedInEventSource; >>>>>>>>> >>>>>>>>> >>>>>>>>> The benefit of an own @Async annotation > over extending e.g. >>>>> the @Event >>>>>>>>> annotation is that it would be perfectly > backward compatible. >>>>> This code >>>>>>> would >>>>>>>>> also run on CDI-1.0 .. 1.2 containers (as > all annotations >>>>> which are not >>>>>>>>> available on the classpath will simply be > ignored by the JVM. >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. > > _______________________________________________ > 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 Feb 11 09:35:43 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 11 Feb 2015 15:35:43 +0100 Subject: [cdi-dev] Yet Another Doc on Async Event Message-ID: Hi guys, As promised and with a few hours late, I started a compilation of our thought about async events. I hope it could be used as a support to finalize our discussion on the subject in the coming meetings (hope we could close this chapter next wednesday). Most of you have comment right on the doc to keep track of who says what by the suggestion mechanism . If I forgot you raise your hand and I?ll give you access. Doc is here : https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150211/530adf05/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150211/530adf05/attachment.bin From issues at jboss.org Wed Feb 11 10:45:51 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 11 Feb 2015 10:45:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039570#comment-13039570 ] Antoine Sabot-Durand commented on CDI-501: ------------------------------------------ We should definitely clarify this for events before adding async events to the spec. > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 10:46:49 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 11 Feb 2015 10:46:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-501: ------------------------------------- Fix Version/s: 2.0 (discussion) > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > Fix For: 2.0 (discussion) > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 11:42:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 11 Feb 2015 11:42:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039594#comment-13039594 ] Mark Struberg commented on CDI-501: ----------------------------------- I think it's implicitly defined as we say that we use standard CDI events for our own Extensions. And all the extension event processing heavily relies on the mutated event instance. So fire() really needs to wait. Could be made clearer though... > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > Fix For: 2.0 (discussion) > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Feb 11 11:54:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 11 Feb 2015 11:54:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039600#comment-13039600 ] Jozef Hartinger commented on CDI-501: ------------------------------------- Right, also the fact that an observer invocation is required to be done in the same transactional context as the call to fire() strongly suggests that both these calls happen in the same thread. > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jos? Paumard > Fix For: 2.0 (discussion) > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From john.d.ament at gmail.com Wed Feb 11 12:02:21 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 11 Feb 2015 17:02:21 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> Message-ID: Jozef, Most of what you see there is taken from the original doc, since everyone seemed to be in agreement. I think the map is just a safeguard in case of additional boot options available in some implementations (e.g. I think OWB/OpenEJB have some options.. currently OpenEJB supports an embedded CDI boot mode). We spoke a few times about BeanManager vs CDI. BeanManager was preferable since there's no easy way to get the the instance, CDI is easier to get and more aligned with how you would get it. Usually people expect the BeanManager to be injected or available via JNDI, neither would be the case here. Yes, this is the container start API. Sounds like you have some good ideas for things like XML configuration or programmatic configuration, both of which are being tracked under separate tickets. One idea might be for an optional param in the map to control packages to scan/ignore, in that map. We didn't want to over load the CDI interface. It already does a lot. This is really SPI code, CDI even though it's in the spi package is used in a lot of application code. John On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger wrote: > Hi John, some thoughts: > > - instead of using BeanManager it makes more sense to me to return a CDI > instance, which is a more user-friendly API (and it also exposes access to > BeanManager) > - is there a usecase for arbitrary keys of the "params" map or is > Map sufficient? > - if we could move the shutdown() method from CDIContainer to the actual > container handle that we obtain from initialize(), that would look more > object-oriented > - what exactly is initialize() supposed to do? Is it supposed to start > scanning the entire classpath for CDI beans? That could be a problem > especially with spring-boot-like fat jars. I think we need an API to tell > the container which classes / packages to consider. Something like Guice's > binding API perhaps? > > - the proposal makes me wonder whether retrofitting this functionality to > the CDI class wouldn't be a better option. It could look like: > > CDI container = CDI.initialize(); > container.select(Foo.class).get(); > container.shutdown(); > > compare it to: > > CDIContainer container = CDIContainerLoader. getCDIContainer(); > BeanManager manager = container.initialize(); > manager.getBeans(...); > container.shutdown(manager); > > > On 02/10/2015 06:58 PM, John D. Ament wrote: > > All, > > I have the updated API here, and wanted to solicit any final feedback > before updating the google doc and spec pages. > > > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > > Let me know your thoughts. > > Thanks, > > John > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150211/f57ba79d/attachment.html From jharting at redhat.com Thu Feb 12 03:18:33 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 12 Feb 2015 09:18:33 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> Message-ID: <54DC61D9.701@redhat.com> Hi John, comments inline: On 02/11/2015 06:02 PM, John D. Ament wrote: > Jozef, > > Most of what you see there is taken from the original doc, since > everyone seemed to be in agreement. I think the map is just a > safeguard in case of additional boot options available in some > implementations (e.g. I think OWB/OpenEJB have some options.. > currently OpenEJB supports an embedded CDI boot mode). No, I am fine with the map. What I am questioning is the type of the map. Usually, data structures with a similar purpose use Strings as their keys. This applies to ServletContext attributes, InvocationContext data, Servlet request/session attributes and others. I am therefore wondering whether there is a usecase for the proposed unbound key signature or not. > > We spoke a few times about BeanManager vs CDI. BeanManager was > preferable since there's no easy way to get the the instance, CDI is > easier to get and more aligned with how you would get it. Usually > people expect the BeanManager to be injected or available via JNDI, > neither would be the case here. If CDI 2.0 targets Java SE then this container initialization API will become something that ordinary application developers use to start/stop CDI in their applications. It therefore cannot be considered an SPI but instead should be something easy to use. On the other hand, BeanManager is definitely an SPI. It is used in extension, frameworks and generally for integration. Not much by applications directly. Therefore, I don't see how the container bootstrap API and BeanManager fit together. IMO the bootstrap API should expose something that makes common tasks (obtaining a contextual reference and firing and event) easy, which the CDI class does. Plus do not forget that BeanManager can be obtained easily using CDI.getBeanManager(). > > Yes, this is the container start API. Sounds like you have some good > ideas for things like XML configuration or programmatic configuration, > both of which are being tracked under separate tickets. One idea > might be for an optional param in the map to control packages to > scan/ignore, in that map. I am wondering whether this configuration should be something optional built on top of the bootstrap API or whether we should consider making it mandatory. Either way, we cannot add the bootstrap API to the spec without explicitly defining how it behaves. My implicit assumption of the proposal is that the container is supposed to scan the entire classpath for explicit or implicit bean archives (including e.g. rt.jar), discover beans, fire extensions, etc. This worries me as this default behavior is far from being lightweight, which CDI for Java SE initially aimed to be. > > We didn't want to over load the CDI interface. It already does a > lot. This is really SPI code, CDI even though it's in the spi package > is used in a lot of application code. I would personally prefer to have it all in one place. Having CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more difficult to know when to use what. > > John > > On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > wrote: > > Hi John, some thoughts: > > - instead of using BeanManager it makes more sense to me to return > a CDI instance, which is a more user-friendly API (and it also > exposes access to BeanManager) > - is there a usecase for arbitrary keys of the "params" map or is > Map sufficient? > - if we could move the shutdown() method from CDIContainer to the > actual container handle that we obtain from initialize(), that > would look more object-oriented > - what exactly is initialize() supposed to do? Is it supposed to > start scanning the entire classpath for CDI beans? That could be a > problem especially with spring-boot-like fat jars. I think we need > an API to tell the container which classes / packages to consider. > Something like Guice's binding API perhaps? > > - the proposal makes me wonder whether retrofitting this > functionality to the CDI class wouldn't be a better option. It > could look like: > > CDI container = CDI.initialize(); > container.select(Foo.class).get(); > container.shutdown(); > > compare it to: > > CDIContainer container = CDIContainerLoader. getCDIContainer(); > BeanManager manager = container.initialize(); > manager.getBeans(...); > container.shutdown(manager); > > > On 02/10/2015 06:58 PM, John D. Ament wrote: >> All, >> >> I have the updated API here, and wanted to solicit any final >> feedback before updating the google doc and spec pages. >> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >> Let me know your thoughts. >> >> Thanks, >> >> John >> >> >> _______________________________________________ >> 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/20150212/072e70ec/attachment.html From antoine at sabot-durand.net Thu Feb 12 12:01:53 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 12 Feb 2015 18:01:53 +0100 Subject: [cdi-dev] Yesterday meeting Message-ID: <59893883-9AAB-4888-B447-17AE4A799810@sabot-durand.net> Hi guys, We had a great meeting yesterday closing some important points on async events. You?ll find the minutes here : http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-02-11-17.00.html The last big that will be discussed next week will be about activation point (should we have trigger on both event producer and even consumer to make it async or can we only have this flag on the producer side). Please take a look at the reference doc https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing and especially 8.2 paragraph. If we find a way to fix issues listed in this part we could keep activation on producer only. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150212/e288eeab/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150212/e288eeab/attachment-0001.bin From abhirockzz at gmail.com Fri Feb 13 01:43:30 2015 From: abhirockzz at gmail.com (Abhishek Gupta) Date: Fri, 13 Feb 2015 12:13:30 +0530 Subject: [cdi-dev] Clarification: CDI and its relationship with Session beans Message-ID: Hello folks - just wanted to gain some clarity here *Section 1.2.2* of the spec doc states that [quote] *Any session bean instance obtained via the dependency injection service is a contextual instance. It is bound to a lifecycle context and is available to other objects that execute in that context. The container automatically creates the instance when it is needed by a client. When the context ends,the container automatically destroys the instance* [/quote] (being a relative beginner) My first impression after reading this statement was the following - "*If I use @Inject for DI of an EJB into my class, the CDI container takes over it's control and actually destroys the instance after the context ends*". If we think in terms of @Stateless EJBs, this *might *not be the case, since the EJB container might choose to return the instance to back to the EJB pool (I understand that this is not mandated by the EJB spec). Keeping this in mind, do you think that the statement in section 1.2.2 is correctly framed since it seems as if the CDI container will actually destroy the EJB instance? I think this is better specified in *Section 7.3.3* (this section dives in deeper) [quote] *When the destroy() method is called, the container simply discards this internal reference*.[/quote] This might be a minor thing - but I am just trying to provide a 'beginner' point of view of and how he/she might interpret the contents of the specification with regards to its relationship with EJBs Feel free to correct me in case I am missing something. Best Regards Abhishek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150213/0b8e7126/attachment.html From arjan.tijms at gmail.com Fri Feb 13 05:07:08 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 13 Feb 2015 11:07:08 +0100 Subject: [cdi-dev] Clarification: CDI and its relationship with Session beans In-Reply-To: References: Message-ID: Hi, On Friday, February 13, 2015, Abhishek Gupta wrote: > Hello folks - just wanted to gain some clarity here > > *Section 1.2.2* of the spec doc states that > > [quote] *Any session bean instance obtained via the dependency injection > service is a contextual instance. It is bound to a lifecycle context and is > available to other objects that execute in that context. The container > automatically creates the instance when it is needed by a client. When the > context ends,the container automatically destroys the instance* [/quote] > > (being a relative beginner) My first impression after reading this > statement was the following - "*If I use @Inject for DI of an EJB into my > class, the CDI container takes over it's control and actually destroys the > instance after the context ends*". > > If we think in terms of @Stateless EJBs, this *might *not be the case > Indeed, and I would even say IS not the case. Even if the container would not pool instances (like JBoss effectively does since Wildfly 8), then every call to the injected bean can still go to another instance of the injected bean. There's therefor IMHO no concept of a bean to destroy, since there was never any particular instance associated with the context in which the bean was injected. The way I see it, a stateless bean from the point of view of a client is close to an MDB or Servlet. You "send" a call to it, but there are no guarantees which actual instance is going to service it. Hope this is correct and hope it helps, Kind regards, Arjan Tijms > since the EJB container might choose to return the instance to back to the > EJB pool (I understand that this is not mandated by the EJB spec). Keeping > this in mind, do you think that the statement in section 1.2.2 is correctly > framed since it seems as if the CDI container will actually destroy the EJB > instance? > > I think this is better specified in *Section 7.3.3* (this section dives > in deeper) > > [quote] *When the destroy() method is called, the container simply > discards this internal reference*.[/quote] > > This might be a minor thing - but I am just trying to provide a 'beginner' > point of view of and how he/she might interpret the contents of the > specification with regards to its relationship with EJBs > > Feel free to correct me in case I am missing something. > > Best Regards > Abhishek > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150213/f3117b49/attachment.html From abhirockzz at gmail.com Fri Feb 13 07:31:36 2015 From: abhirockzz at gmail.com (Abhishek Gupta) Date: Fri, 13 Feb 2015 18:01:36 +0530 Subject: [cdi-dev] Clarification: CDI and its relationship with Session beans In-Reply-To: References: Message-ID: Thanks Arjan. This definitely helped. My basic point was that the statement in *Section 1.2.2* implies that the *CDI container destroys the Session bean instance* - which is definitely not the case (you seem to share the same opinion), because the CDI container is dealing with a proxy anyway. *Section 7.3.3* conveys this more accurately IMO. That's I wanted to point this out and check what the experts feel about (maybe slightly) re-wording Section 1.2.2 to avoid any ambiguity or confusion :-) Regards Abhishek On Fri, Feb 13, 2015 at 3:37 PM, arjan tijms wrote: > Hi, > > On Friday, February 13, 2015, Abhishek Gupta wrote: > >> Hello folks - just wanted to gain some clarity here >> >> *Section 1.2.2* of the spec doc states that >> >> [quote] *Any session bean instance obtained via the dependency injection >> service is a contextual instance. It is bound to a lifecycle context and is >> available to other objects that execute in that context. The container >> automatically creates the instance when it is needed by a client. When the >> context ends,the container automatically destroys the instance* [/quote] >> >> (being a relative beginner) My first impression after reading this >> statement was the following - "*If I use @Inject for DI of an EJB into >> my class, the CDI container takes over it's control and actually destroys >> the instance after the context ends*". >> >> If we think in terms of @Stateless EJBs, this *might *not be the case >> > > Indeed, and I would even say IS not the case. Even if the container would > not pool instances (like JBoss effectively does since Wildfly 8), then > every call to the injected bean can still go to another instance of the > injected bean. > > There's therefor IMHO no concept of a bean to destroy, since there was > never any particular instance associated with the context in which the bean > was injected. > > The way I see it, a stateless bean from the point of view of a client is > close to an MDB or Servlet. You "send" a call to it, but there are no > guarantees which actual instance is going to service it. > > Hope this is correct and hope it helps, > > Kind regards, > Arjan Tijms > > > > >> since the EJB container might choose to return the instance to back to >> the EJB pool (I understand that this is not mandated by the EJB spec). >> Keeping this in mind, do you think that the statement in section 1.2.2 is >> correctly framed since it seems as if the CDI container will actually >> destroy the EJB instance? >> >> I think this is better specified in *Section 7.3.3* (this section dives >> in deeper) >> >> [quote] *When the destroy() method is called, the container simply >> discards this internal reference*.[/quote] >> >> This might be a minor thing - but I am just trying to provide a >> 'beginner' point of view of and how he/she might interpret the contents of >> the specification with regards to its relationship with EJBs >> >> Feel free to correct me in case I am missing something. >> >> Best Regards >> Abhishek >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150213/f067df28/attachment.html From issues at jboss.org Fri Feb 13 08:25:48 2015 From: issues at jboss.org (Abhishek Gupta (JIRA)) Date: Fri, 13 Feb 2015 08:25:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: Abhishek Gupta created CDI-507: ---------------------------------- Summary: CDI support for Singleton Pseudo Scope Key: CDI-507 URL: https://issues.jboss.org/browse/CDI-507 Project: CDI Specification Issues Issue Type: Clarification Environment: --NA-- (documentation) Reporter: Abhishek Gupta Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) Just wanted to confirm which whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 13 08:26:48 2015 From: issues at jboss.org (Abhishek Gupta (JIRA)) Date: Fri, 13 Feb 2015 08:26:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Gupta updated CDI-507: ------------------------------- Description: Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? was: Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) Just wanted to confirm which whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? > CDI support for Singleton Pseudo Scope > -------------------------------------- > > Key: CDI-507 > URL: https://issues.jboss.org/browse/CDI-507 > Project: CDI Specification Issues > Issue Type: Clarification > Environment: --NA-- (documentation) > Reporter: Abhishek Gupta > > Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. > As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) > Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Wed Feb 18 04:37:43 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 18 Feb 2015 10:37:43 +0100 Subject: [cdi-dev] Extension handling in EARs Message-ID: Hi! I had some hard time to make DeltaSpike really portable and thus i wrote up a blog post about it yesterday: https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) So please lets continue the arguments over here. LieGrue, strub From arjan.tijms at gmail.com Wed Feb 18 06:02:48 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 18 Feb 2015 12:02:48 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: Hi, On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: > https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ Interesting write up! Over at OmniFaces we had some major issues with this as well, and blogged about that experience a little over a year ago. See http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html We also compiled an overview of what works and doesn't work with CDI and ears from our perspective here: https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) Kind regards, Arjan Tijms > > There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) > > So please lets continue the arguments over here. > > LieGrue, > strub > > > > _______________________________________________ > 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 struberg at yahoo.de Wed Feb 18 09:19:22 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 18 Feb 2015 15:19:22 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. Arjans experience is only the tip of the iceberg. @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. Of course, the other approaches have their downsides as well? LieGrue, strub > Am 18.02.2015 um 12:02 schrieb arjan tijms : > > Hi, > > On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ > > Interesting write up! > > Over at OmniFaces we had some major issues with this as well, and > blogged about that experience a little over a year ago. See > http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html > > We also compiled an overview of what works and doesn't work with CDI > and ears from our perspective here: > https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) > > Kind regards, > Arjan Tijms > > > > >> >> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >> >> So please lets continue the arguments over here. >> >> LieGrue, >> strub >> >> >> >> _______________________________________________ >> 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 Feb 18 09:29:19 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Feb 2015 15:29:19 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: Mark seems there are multiple topics and can maybe be better to split them accross threads to avoid to cross topics and finally be lost easily. Here the ones I see: -> BDA BM (what it means, usability in real apps = outside of TCKs) - this is also the question of the modularity of CDI. there are few pointers in the spec but seems it is only implemented this way in few containers. The question of deployment/runtime consistency if important as well. 1 BM by jar is quickly broken because you can write any lib (too restricted visibility) + "jar" sometimes doesnt mean anything (but deployment does). -> EAR and bean managers (1 by jar? 1 by sub app? 1 for lib + 1 by webapp? 1 for the whole app?) -> (if previous answer is not 1 for the whole app) EAR and bean propagation/inheritance -> same as previous with events (splitting in container events and runtime events I think) -> EAR and different use cases (1) just a packaging for my app, 2) aggregating existing app => both needs different meaning for the same scopes relatively quickly :s) Hope I was more or less clear on this fuzzy topic Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-18 15:19 GMT+01:00 Mark Struberg : > I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? > > What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? > If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. > > Arjans experience is only the tip of the iceberg. > @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. > > > I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. > > Of course, the other approaches have their downsides as well? > > LieGrue, > strub > > >> Am 18.02.2015 um 12:02 schrieb arjan tijms : >> >> Hi, >> >> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >> >> Interesting write up! >> >> Over at OmniFaces we had some major issues with this as well, and >> blogged about that experience a little over a year ago. See >> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >> >> We also compiled an overview of what works and doesn't work with CDI >> and ears from our perspective here: >> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >> >> Kind regards, >> Arjan Tijms >> >> >> >> >>> >>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>> >>> So please lets continue the arguments over here. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> _______________________________________________ >>> 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 jharting at redhat.com Wed Feb 18 09:54:16 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Feb 2015 15:54:16 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: <54E4A798.3010603@redhat.com> On 02/18/2015 03:19 PM, Mark Struberg wrote: > I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. > What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. > > What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? > If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. > > Arjans experience is only the tip of the iceberg. > @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. > > > I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. > > Of course, the other approaches have their downsides as well? > > LieGrue, > strub > > >> Am 18.02.2015 um 12:02 schrieb arjan tijms : >> >> Hi, >> >> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >> Interesting write up! >> >> Over at OmniFaces we had some major issues with this as well, and >> blogged about that experience a little over a year ago. See >> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >> >> We also compiled an overview of what works and doesn't work with CDI >> and ears from our perspective here: >> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >> >> Kind regards, >> Arjan Tijms >> >> >> >> >>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>> >>> So please lets continue the arguments over here. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> _______________________________________________ >>> 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 jharting at redhat.com Wed Feb 18 09:58:24 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Feb 2015 15:58:24 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: <54E4A890.8030608@redhat.com> BeanManager granularity should have no impact on visibility. Visibility is defined in the spec. Perhaps you can elaborate as I don't follow what you meant by this part: On 02/18/2015 03:29 PM, Romain Manni-Bucau wrote: > 1 BM by jar is quickly broken because you can write > any lib (too restricted visibility) + "jar" sometimes doesnt mean > anything (but deployment does). From antoine at sabot-durand.net Wed Feb 18 10:03:50 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Feb 2015 16:03:50 +0100 Subject: [cdi-dev] Unavailable for today meeting Message-ID: <2C1BFB26-6D06-4FFA-99D5-2E0E2E30C40C@sabot-durand.net> Hi guys, I won?t make it for today. Let?s schedule meeting for net wednesday. Sorry, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150218/9fb64e71/attachment.bin From issues at jboss.org Wed Feb 18 10:16:49 2015 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Wed, 18 Feb 2015 10:16:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated CDI-498: ------------------------------------- Forum Reference: https://developer.jboss.org/people/mkouba/blog/2012/08/30/seam-vs-cdi-conversations--pay-attention-to-rerendering > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Wed Feb 18 10:20:35 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 18 Feb 2015 16:20:35 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: Message-ID: <19EE2B31-354C-4CE6-833F-0DE0834DECDB@yahoo.de> Totally agree that a jar is not a native part of an app. It?s just a random entry in the classpath. Especially since older Glassfish and JBossAS versions were totally broken in regard to BDA there are still tons of projects who simply unpack all the jars into WEB-INF/classes. Also all the projects wo do re-packaging for OSGi related reasonst or ?shading? into another jar. BDA==JAR just totally didn?t work out. And btw this also contradicts section 5 of the CDI spec. As discussed a dozen of times: the CDI spec contradicts itself and has 2 different definitions for ?BDA?. And I like the one of paragraph 4 (which basically follows EE module boundaries) way better ;) LieGrue, strub > Am 18.02.2015 um 15:29 schrieb Romain Manni-Bucau : > > Mark > > seems there are multiple topics and can maybe be better to split them > accross threads to avoid to cross topics and finally be lost easily. > > Here the ones I see: > > -> BDA BM (what it means, usability in real apps = outside of TCKs) - > this is also the question of the modularity of CDI. there are few > pointers in the spec but seems it is only implemented this way in few > containers. The question of deployment/runtime consistency if > important as well. 1 BM by jar is quickly broken because you can write > any lib (too restricted visibility) + "jar" sometimes doesnt mean > anything (but deployment does). > -> EAR and bean managers (1 by jar? 1 by sub app? 1 for lib + 1 by > webapp? 1 for the whole app?) > -> (if previous answer is not 1 for the whole app) EAR and bean > propagation/inheritance > -> same as previous with events (splitting in container events and > runtime events I think) > -> EAR and different use cases (1) just a packaging for my app, 2) > aggregating existing app => both needs different meaning for the same > scopes relatively quickly :s) > > Hope I was more or less clear on this fuzzy topic > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-18 15:19 GMT+01:00 Mark Struberg : >> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >> >> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >> >> Arjans experience is only the tip of the iceberg. >> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >> >> >> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >> >> Of course, the other approaches have their downsides as well? >> >> LieGrue, >> strub >> >> >>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>> >>> Hi, >>> >>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>> >>> Interesting write up! >>> >>> Over at OmniFaces we had some major issues with this as well, and >>> blogged about that experience a little over a year ago. See >>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>> >>> We also compiled an overview of what works and doesn't work with CDI >>> and ears from our perspective here: >>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>>> >>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>> >>>> So please lets continue the arguments over here. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 struberg at yahoo.de Wed Feb 18 10:47:53 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 18 Feb 2015 16:47:53 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E4A798.3010603@redhat.com> References: <54E4A798.3010603@redhat.com> Message-ID: <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> Again, just trying to understand how it works in Weld. Lets do the following example: MessageBundleExtension in DeltaSpike [1]. We have an public interface @MessageBundle MsgInEar { .. } in a shared ear lib jar and a second one public interface @MessageBundle MsgInWar { .. } in WEB-INF/classes of war1. In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. Questions: Q1: Which BeanManager do I get here? Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? Q3: Does this create an AmbiguousResolutionException when used? LieGrue, strub PS: I am well aware that all the other solutions also have some very nasty side effects? [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : > > > On 02/18/2015 03:19 PM, Mark Struberg wrote: >> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. > That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? > That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >> >> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >> >> Arjans experience is only the tip of the iceberg. >> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >> >> >> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >> >> Of course, the other approaches have their downsides as well? >> >> LieGrue, >> strub >> >> >>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>> >>> Hi, >>> >>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>> Interesting write up! >>> >>> Over at OmniFaces we had some major issues with this as well, and >>> blogged about that experience a little over a year ago. See >>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>> >>> We also compiled an overview of what works and doesn't work with CDI >>> and ears from our perspective here: >>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>> >>>> So please lets continue the arguments over here. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Feb 18 10:54:30 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Feb 2015 16:54:30 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> Message-ID: @jozef: if you get interceptors for instance from an injected bm you dont get your app ones but jar ones even from a war which breaks comon usages as well as classloader design where location doesnt mean anything for cdi. Le 18 f?vr. 2015 16:48, "Mark Struberg" a ?crit : > Again, just trying to understand how it works in Weld. > > Lets do the following example: MessageBundleExtension in DeltaSpike [1]. > > We have an > public interface @MessageBundle MsgInEar { .. } > in a shared ear lib jar and a second one > public interface @MessageBundle MsgInWar { .. } > in WEB-INF/classes of war1. > > In Weld there is only 1 instance of the MessageBundleExtension for the > whole EAR, right? > > This extension first collects all the classes annotated with > @MessageBundle in a Set> via @Observes ProcessAnnotatedType. > And in @Observes AfterBeanDiscovery we create Bean for all those found > classes and add all those to the BeanManager we get as parameter. > > Questions: > Q1: Which BeanManager do I get here? > Q2: And what happens if I add a Bean with a Type X in war1 and another > Bean with Type X in war2 via AfterBeanDiscovery#addBean()? > Q3: Does this create an AmbiguousResolutionException when used? > > LieGrue, > strub > > PS: I am well aware that all the other solutions also have some very nasty > side effects? > > [1] > http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > > > > Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : > > > > > > On 02/18/2015 03:19 PM, Mark Struberg wrote: > >> I fear the clash in bean names across different WARs is a bug which is > the direct consequence of Weld only has 1 ?User BeanManager?. It seems > there are multiple kind of BeanManagers in Weld. The one that Jozef already > describes is the ?BDA BeanManager?. But there must be another one. > > That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss > EAP. > >> What happens to all the AfterBeanDiscovery#addBean() beans? Where do > they get stored in App servers using Weld? > > That should be an implementation detail. What matters where the bean is > visible from - i.e. if the bean class comes from a shared lib, it should be > visible globally whereas if it comes from a war it should not be visible > from another war. > >> > >> What happens to BeforeBeanDiscovery#addScope and > AfterBeanDiscovery#addContext ? > >> If I package deltaspike-jsf (which activates the a few JSF related > Contexts) in one of my WARs, do I get those also for my other WARs? What if > a 2nd war tries to register the same Context? I guess this is what Romain > meant when he wanted to treat each WAR as (mostly) isolated unit. > >> > >> Arjans experience is only the tip of the iceberg. > >> @Arjan, I would be interested if you would run your tests against > TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of > workarounds to get it running on Weld. But still would love to know how far > (or not) portability goes. > >> > >> > >> I do fully agree with ?1 Extension instance per Application? paragraph. > But the important question is what Appliation means. This is by far not > clear. The EE spec for example talks about ?multiple Applications in an > EAR? in some paragraphs (meaning Web-Apps it seems). So both > interpretations are ok by the strict spec wording. > >> > >> Of course, the other approaches have their downsides as well? > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 18.02.2015 um 12:02 schrieb arjan tijms : > >>> > >>> Hi, > >>> > >>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg > wrote: > >>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ > >>> Interesting write up! > >>> > >>> Over at OmniFaces we had some major issues with this as well, and > >>> blogged about that experience a little over a year ago. See > >>> > http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html > >>> > >>> We also compiled an overview of what works and doesn't work with CDI > >>> and ears from our perspective here: > >>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) > >>> > >>> Kind regards, > >>> Arjan Tijms > >>> > >>> > >>> > >>> > >>>> There was a lively discussion on twitter but 140 chars is way too > restrictive to have a good flow ;) > >>>> > >>>> So please lets continue the arguments over here. > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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. > > > > > _______________________________________________ > 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/20150218/7d1182cf/attachment-0001.html From werner.keil at gmail.com Wed Feb 18 11:12:46 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 18 Feb 2015 17:12:46 +0100 Subject: [cdi-dev] Unavailable for today meeting Message-ID: Antoine/all, Sorry to hear. Btw, since CDI is hosted by GitHub, maybe some of you saw the new Gitter chat feature Raj kindly invited me to the other day. JSR 377 started using it: https://gitter.im/jsr377, I also created a similar room for Agorava https://gitter.im/agorava Would that be an option for future chat sessions or do you prefer IRC? Even though there is at least one working Web client, it seems far less intuitive than Gitter at least in my impression. Gitter automatically persists all sessions, and though there wasn't enough time to fully test it, an archive link like https://gitter.im/jsr377/archives/all suggests, conversations won't be thrown away too easily or may even stay there forever;-) Cheers, Werner On Wed, Feb 18, 2015 at 4:16 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. Re: Extension handling in EARs (arjan tijms) > 2. Re: Extension handling in EARs (Mark Struberg) > 3. Re: Extension handling in EARs (Romain Manni-Bucau) > 4. Re: Extension handling in EARs (Jozef Hartinger) > 5. Re: Extension handling in EARs (Jozef Hartinger) > 6. Unavailable for today meeting (Antoine Sabot-Durand) > 7. [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation > interface" - dots are not valid in EL name > (SBS JIRA Integration (JIRA)) > > > ------------------------------ > > Message: 6 > Date: Wed, 18 Feb 2015 16:03:50 +0100 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Unavailable for today meeting > To: cdi-dev > Message-ID: <2C1BFB26-6D06-4FFA-99D5-2E0E2E30C40C at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi guys, > > > I won?t make it for today. Let?s schedule meeting for net wednesday. > > Sorry, > > 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. > > End of cdi-dev Digest, Vol 51, Issue 28 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150218/0dd5b522/attachment.html From jharting at redhat.com Wed Feb 18 11:39:22 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Feb 2015 17:39:22 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> Message-ID: <54E4C03A.5070208@redhat.com> What are the bean classes of those additional beans? On 02/18/2015 04:47 PM, Mark Struberg wrote: > Again, just trying to understand how it works in Weld. > > Lets do the following example: MessageBundleExtension in DeltaSpike [1]. > > We have an > public interface @MessageBundle MsgInEar { .. } > in a shared ear lib jar and a second one > public interface @MessageBundle MsgInWar { .. } > in WEB-INF/classes of war1. > > In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? > > This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. > And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. > > Questions: > Q1: Which BeanManager do I get here? > Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? > Q3: Does this create an AmbiguousResolutionException when used? > > LieGrue, > strub > > PS: I am well aware that all the other solutions also have some very nasty side effects? > > [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > > >> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >> >> >> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>> >>> Arjans experience is only the tip of the iceberg. >>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>> >>> >>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>> >>> Of course, the other approaches have their downsides as well? >>> >>> LieGrue, >>> strub >>> >>> >>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>> >>>> Hi, >>>> >>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>> Interesting write up! >>>> >>>> Over at OmniFaces we had some major issues with this as well, and >>>> blogged about that experience a little over a year ago. See >>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>> >>>> We also compiled an overview of what works and doesn't work with CDI >>>> and ears from our perspective here: >>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> >>>> >>>> >>>> >>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>> >>>>> So please lets continue the arguments over here. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 struberg at yahoo.de Wed Feb 18 14:49:54 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 18 Feb 2015 20:49:54 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E4C03A.5070208@redhat.com> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> Message-ID: There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). Both can be either in the shared ear lib jar or in any of the WARs. So we have 4 cases to look at. LieGrue, strub > Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : > > What are the bean classes of those additional beans? > > On 02/18/2015 04:47 PM, Mark Struberg wrote: >> Again, just trying to understand how it works in Weld. >> >> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >> >> We have an >> public interface @MessageBundle MsgInEar { .. } >> in a shared ear lib jar and a second one >> public interface @MessageBundle MsgInWar { .. } >> in WEB-INF/classes of war1. >> >> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >> >> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >> >> Questions: >> Q1: Which BeanManager do I get here? >> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >> Q3: Does this create an AmbiguousResolutionException when used? >> >> LieGrue, >> strub >> >> PS: I am well aware that all the other solutions also have some very nasty side effects? >> >> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >> >> >>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>> >>> >>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>> >>>> Arjans experience is only the tip of the iceberg. >>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>> >>>> >>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>> >>>> Of course, the other approaches have their downsides as well? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>> >>>>> Hi, >>>>> >>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>> Interesting write up! >>>>> >>>>> Over at OmniFaces we had some major issues with this as well, and >>>>> blogged about that experience a little over a year ago. See >>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>> >>>>> We also compiled an overview of what works and doesn't work with CDI >>>>> and ears from our perspective here: >>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> >>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>> >>>>>> So please lets continue the arguments over here. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 jharting at redhat.com Thu Feb 19 03:48:13 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Feb 2015 09:48:13 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> Message-ID: <54E5A34D.1070003@redhat.com> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: A - in a shared jar B - in a war Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries So far we'll hopefully on the same page. Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: ABean - is injectable into beans anywhere in the entire EAR BBean - is not injectable outside of the given war HTH, Jozef On 02/18/2015 08:49 PM, Mark Struberg wrote: > There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). > > Both can be either in the shared ear lib jar or in any of the WARs. > So we have 4 cases to look at. > > LieGrue, > strub > > > >> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >> >> What are the bean classes of those additional beans? >> >> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>> Again, just trying to understand how it works in Weld. >>> >>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>> >>> We have an >>> public interface @MessageBundle MsgInEar { .. } >>> in a shared ear lib jar and a second one >>> public interface @MessageBundle MsgInWar { .. } >>> in WEB-INF/classes of war1. >>> >>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>> >>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>> >>> Questions: >>> Q1: Which BeanManager do I get here? >>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>> Q3: Does this create an AmbiguousResolutionException when used? >>> >>> LieGrue, >>> strub >>> >>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>> >>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>> >>> >>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>> >>>> >>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>> >>>>> Arjans experience is only the tip of the iceberg. >>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>> >>>>> >>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>> >>>>> Of course, the other approaches have their downsides as well? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>> Interesting write up! >>>>>> >>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>> blogged about that experience a little over a year ago. See >>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>> >>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>> and ears from our perspective here: >>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>> >>>>>> Kind regards, >>>>>> Arjan Tijms >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>> >>>>>>> So please lets continue the arguments over here. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 antoine at sabot-durand.net Thu Feb 19 04:32:01 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Feb 2015 10:32:01 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts Message-ID: Hi All, Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? Thanks for your input on that point. Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/22251e5b/attachment.bin From antoine at sabot-durand.net Thu Feb 19 05:04:31 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Feb 2015 11:04:31 +0100 Subject: [cdi-dev] Meet our new ambassador Message-ID: <559D9756-82CB-451F-9D2D-A1DCD9246854@sabot-durand.net> Hi All, With the idea to increase CDI notoriety we ask JBoss design team to work on CDI Logo. Creating an identity for something as abstract as CDI is not very easy so we asked the design team to avoid corporate logo and give a true identity to CDI thru a mascot. So meet our new ambassador and logo : I have a bunch of graphic elements (http://design.jboss.org/cdi/index.htm) to switch our look and feel on the web and on social network. We?re even ready to have T-Shirts and other swag that can be ordered here: http://www.cafepress.com/jbossorg/12231128 These stuff will make nice giveaways for conferences to help creating a CDI brand and raise the adoption of the spec. Now, this bearded fellow has still no name. Cildmi was the first name to come to my mind, but perhaps you have better ideas? Regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/0455e60e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 2663 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/0455e60e/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/0455e60e/attachment.bin From rmannibucau at gmail.com Thu Feb 19 05:22:14 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 11:22:14 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: Hi I'm +1 for it but it needs important changes (= surely new contexts). Typically we can't change today @RequestScoped (which has no link with a request but only with a thread!). So we could have @RequestScoped (~ @ThreadLocalScoped) and @InheritedRequestScoped which would be a real request scope (but not an InheritedThreadLocal please) For the request it makes a lot of sense since you need to stay thread safe even accross threads (servlet spec) and avoids to be forced to use message passing which - even if a good pattern - adds boilerplate code for simple async needs. For JAXRS I dont know since it is really suspend/resume semantic so request scope maybe doesnt makes much sense here (there is a break in the flow). Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand : > Hi All, > > Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? > > Thanks for your input on that point. > > 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 Thu Feb 19 06:17:12 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Feb 2015 12:17:12 +0100 Subject: [cdi-dev] Revamped blog section on the site Message-ID: Hi all, I just finish revamping the ?news? section on the site. Remember that your contribution on this section is always welcome, all instruction are here: https://github.com/cdi-spec/cdi-spec.org/blob/master/README.adoc Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/69257968/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/69257968/attachment.bin From thjanssen123 at gmail.com Thu Feb 19 06:45:25 2015 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Thu, 19 Feb 2015 12:45:25 +0100 Subject: [cdi-dev] Meet our new ambassador In-Reply-To: <559D9756-82CB-451F-9D2D-A1DCD9246854@sabot-durand.net> References: <559D9756-82CB-451F-9D2D-A1DCD9246854@sabot-durand.net> Message-ID: Hi Antoine, under which license are the images licensed? I was told, that most of the JBoss related logos (in that specific case Arquillian) are licensed under a closed one. If that is also the case for the CDI logo, we should better not use it for any social media post or article that is not published on the CDI website. Regards, Thorben -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2015-02-19 11:04 GMT+01:00 Antoine Sabot-Durand : > Hi All, > > > With the idea to increase CDI notoriety we ask JBoss design team to work > on CDI Logo. Creating an identity for something as abstract as CDI is not > very easy so we asked the design team to avoid corporate logo and give a > true identity to CDI thru a mascot. > So meet our new ambassador and logo : > > I have a bunch of graphic elements (http://design.jboss.org/cdi/index.htm) > to switch our look and feel on the web and on social network. We?re even > ready to have T-Shirts and other swag that can be ordered here: > > http://www.cafepress.com/jbossorg/12231128 > > These stuff will make nice giveaways for conferences to help creating a > CDI brand and raise the adoption of the spec. > > Now, this bearded fellow has still no name. Cildmi was the first name to > come to my mind, but perhaps you have better ideas? > > Regards, > > 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/20150219/70bad6e1/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 2663 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/70bad6e1/attachment-0001.png From werner.keil at gmail.com Thu Feb 19 07:03:43 2015 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 19 Feb 2015 13:03:43 +0100 Subject: [cdi-dev] Meet our new ambassador Message-ID: +1 CDImli was the first thing I imagined before even reading the rest of your mail;-) Werner On Thu, Feb 19, 2015 at 12:45 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. Enhancing SPI to support async operation for contexts > (Antoine Sabot-Durand) > 2. Meet our new ambassador (Antoine Sabot-Durand) > 3. Re: Enhancing SPI to support async operation for contexts > (Romain Manni-Bucau) > 4. Revamped blog section on the site (Antoine Sabot-Durand) > 5. Re: Meet our new ambassador (Thorben Janssen) > > > ---------------------------------------------------------------------- > > > > Message: 2 > Date: Thu, 19 Feb 2015 11:04:31 +0100 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Meet our new ambassador > To: cdi-dev > Message-ID: <559D9756-82CB-451F-9D2D-A1DCD9246854 at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi All, > > > With the idea to increase CDI notoriety we ask JBoss design team to work > on CDI Logo. Creating an identity for something as abstract as CDI is not > very easy so we asked the design team to avoid corporate logo and give a > true identity to CDI thru a mascot. > So meet our new ambassador and logo : > > > I have a bunch of graphic elements (http://design.jboss.org/cdi/index.htm) > to switch our look and feel on the web and on social network. We?re even > ready to have T-Shirts and other swag that can be ordered here: > > http://www.cafepress.com/jbossorg/12231128 < > http://www.cafepress.com/jbossorg/12231128> > > These stuff will make nice giveaways for conferences to help creating a > CDI brand and raise the adoption of the spec. > > Now, this bearded fellow has still no name. Cildmi was the first name to > come to my mind, but perhaps you have better ideas? > > Regards, > > Antoine > -------------- next part -------------- > > End of cdi-dev Digest, Vol 51, Issue 31 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/4de2b19b/attachment.html From jharting at redhat.com Thu Feb 19 08:18:09 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Feb 2015 14:18:09 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: <54E5E291.5010204@redhat.com> I agree with Romain that we cannot change the semantics of existing contexts. Furthermore, I think that instead of these tricky context propagations we should promote async event-driven architecture where as much state as needed is carried within the message / event payload itself instead of clients relying on state from context, threadlocal, etc. Jozef On 02/19/2015 10:32 AM, Antoine Sabot-Durand wrote: > Hi All, > > Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? > > Thanks for your input on that point. > > Antoine > > > > From rmannibucau at gmail.com Thu Feb 19 08:19:23 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 14:19:23 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: <54E5E291.5010204@redhat.com> References: <54E5E291.5010204@redhat.com> Message-ID: +1 excepted for servlet requests where we can significantly do better but that's surely better to deal with it in another thread? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 14:18 GMT+01:00 Jozef Hartinger : > I agree with Romain that we cannot change the semantics of existing > contexts. > > Furthermore, I think that instead of these tricky context propagations > we should promote async event-driven architecture where as much state as > needed is carried within the message / event payload itself instead of > clients relying on state from context, threadlocal, etc. > > Jozef > > On 02/19/2015 10:32 AM, Antoine Sabot-Durand wrote: >> Hi All, >> >> Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? >> Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? >> >> Thanks for your input on that point. >> >> 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 struberg at yahoo.de Thu Feb 19 09:21:27 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 15:21:27 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E5A34D.1070003@redhat.com> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> Message-ID: <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. And as expected it is pretty much non-portable (to avoid the word ?broken?). The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? LieGrue, strub > Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : > > OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: > > A - in a shared jar > B - in a war > > Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: > > A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) > B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries > > So far we'll hopefully on the same page. > > Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). > > What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: > > ABean - is injectable into beans anywhere in the entire EAR > BBean - is not injectable outside of the given war > > HTH, > > Jozef > > > On 02/18/2015 08:49 PM, Mark Struberg wrote: >> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >> >> Both can be either in the shared ear lib jar or in any of the WARs. >> So we have 4 cases to look at. >> >> LieGrue, >> strub >> >> >> >>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>> >>> What are the bean classes of those additional beans? >>> >>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>> Again, just trying to understand how it works in Weld. >>>> >>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>> >>>> We have an >>>> public interface @MessageBundle MsgInEar { .. } >>>> in a shared ear lib jar and a second one >>>> public interface @MessageBundle MsgInWar { .. } >>>> in WEB-INF/classes of war1. >>>> >>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>> >>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>> >>>> Questions: >>>> Q1: Which BeanManager do I get here? >>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>> Q3: Does this create an AmbiguousResolutionException when used? >>>> >>>> LieGrue, >>>> strub >>>> >>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>> >>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>> >>>> >>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>> >>>>> >>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>> >>>>>> Arjans experience is only the tip of the iceberg. >>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>> >>>>>> >>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>> >>>>>> Of course, the other approaches have their downsides as well? >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>> Interesting write up! >>>>>>> >>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>> blogged about that experience a little over a year ago. See >>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>> >>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>> and ears from our perspective here: >>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan Tijms >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>> >>>>>>>> So please lets continue the arguments over here. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 arjan.tijms at gmail.com Thu Feb 19 09:32:53 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 Feb 2015 15:32:53 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> Message-ID: Hi, On Thu, Feb 19, 2015 at 3:21 PM, Mark Struberg wrote: > And as expected it is pretty much non-portable (to avoid the word ?broken?). I don't use the word often, but I think we should call it what it is here; "broken", unfortunately. Kind regards, Arjan > The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. > > It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? > > EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. > > We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? > > LieGrue, > strub > > > >> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >> >> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >> >> A - in a shared jar >> B - in a war >> >> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >> >> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >> >> So far we'll hopefully on the same page. >> >> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >> >> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >> >> ABean - is injectable into beans anywhere in the entire EAR >> BBean - is not injectable outside of the given war >> >> HTH, >> >> Jozef >> >> >> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>> >>> Both can be either in the shared ear lib jar or in any of the WARs. >>> So we have 4 cases to look at. >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>> >>>> What are the bean classes of those additional beans? >>>> >>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>> Again, just trying to understand how it works in Weld. >>>>> >>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>> >>>>> We have an >>>>> public interface @MessageBundle MsgInEar { .. } >>>>> in a shared ear lib jar and a second one >>>>> public interface @MessageBundle MsgInWar { .. } >>>>> in WEB-INF/classes of war1. >>>>> >>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>> >>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>> >>>>> Questions: >>>>> Q1: Which BeanManager do I get here? >>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>> >>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>> >>>>> >>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>> >>>>>> >>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>> >>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>> >>>>>>> >>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>> >>>>>>> Of course, the other approaches have their downsides as well? >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>> Interesting write up! >>>>>>>> >>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>> >>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>> and ears from our perspective here: >>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan Tijms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>> >>>>>>>>> So please lets continue the arguments over here. >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >> > > > _______________________________________________ > 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 pmuir at redhat.com Thu Feb 19 10:20:57 2015 From: pmuir at redhat.com (Pete Muir) Date: Thu, 19 Feb 2015 15:20:57 +0000 Subject: [cdi-dev] Meet our new ambassador In-Reply-To: References: <559D9756-82CB-451F-9D2D-A1DCD9246854@sabot-durand.net> Message-ID: <5FC03086-3F1D-42DA-BCEB-52907B42CD2B@redhat.com> We are looking in to this, stay tuned :-) > On 19 Feb 2015, at 11:45, Thorben Janssen wrote: > > Hi Antoine, > > under which license are the images licensed? > I was told, that most of the JBoss related logos (in that specific case Arquillian) are licensed under a closed one. If that is also the case for the CDI logo, we should better not use it for any social media post or article that is not published on the CDI website. > > Regards, > Thorben > > -- > Thorben Janssen > > @thjanssen123 > www.thoughts-on-java.org > > 2015-02-19 11:04 GMT+01:00 Antoine Sabot-Durand >: > Hi All, > > > With the idea to increase CDI notoriety we ask JBoss design team to work on CDI Logo. Creating an identity for something as abstract as CDI is not very easy so we asked the design team to avoid corporate logo and give a true identity to CDI thru a mascot. > So meet our new ambassador and logo : > > > I have a bunch of graphic elements (http://design.jboss.org/cdi/index.htm ) to switch our look and feel on the web and on social network. We?re even ready to have T-Shirts and other swag that can be ordered here: > > http://www.cafepress.com/jbossorg/12231128 > > These stuff will make nice giveaways for conferences to help creating a CDI brand and raise the adoption of the spec. > > Now, this bearded fellow has still no name. Cildmi was the first name to come to my mind, but perhaps you have better ideas? > > Regards, > > 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. > > _______________________________________________ > 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/20150219/f3cb9e3b/attachment.html From jharting at redhat.com Thu Feb 19 10:53:25 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Feb 2015 16:53:25 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> Message-ID: <54E606F5.2030207@redhat.com> On 02/19/2015 03:21 PM, Mark Struberg wrote: > I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. > > And as expected it is pretty much non-portable (to avoid the word ?broken?). > The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. > > It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. > > EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. > > We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? > > LieGrue, > strub > > > >> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >> >> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >> >> A - in a shared jar >> B - in a war >> >> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >> >> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >> >> So far we'll hopefully on the same page. >> >> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >> >> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >> >> ABean - is injectable into beans anywhere in the entire EAR >> BBean - is not injectable outside of the given war >> >> HTH, >> >> Jozef >> >> >> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>> >>> Both can be either in the shared ear lib jar or in any of the WARs. >>> So we have 4 cases to look at. >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>> >>>> What are the bean classes of those additional beans? >>>> >>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>> Again, just trying to understand how it works in Weld. >>>>> >>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>> >>>>> We have an >>>>> public interface @MessageBundle MsgInEar { .. } >>>>> in a shared ear lib jar and a second one >>>>> public interface @MessageBundle MsgInWar { .. } >>>>> in WEB-INF/classes of war1. >>>>> >>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>> >>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>> >>>>> Questions: >>>>> Q1: Which BeanManager do I get here? >>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>> >>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>> >>>>> >>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>> >>>>>> >>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>> >>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>> >>>>>>> >>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>> >>>>>>> Of course, the other approaches have their downsides as well? >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>> Interesting write up! >>>>>>>> >>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>> >>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>> and ears from our perspective here: >>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan Tijms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>> >>>>>>>>> So please lets continue the arguments over here. >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 sven.linstaedt at gmail.com Thu Feb 19 11:33:55 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 19 Feb 2015 17:33:55 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: Hi, and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded. 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization. 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe. Best regards Sven 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : > Hi > > I'm +1 for it but it needs important changes (= surely new contexts). > Typically we can't change today @RequestScoped (which has no link with > a request but only with a thread!). > > So we could have @RequestScoped (~ @ThreadLocalScoped) and > @InheritedRequestScoped which would be a real request scope (but not > an InheritedThreadLocal please) > > For the request it makes a lot of sense since you need to stay thread > safe even accross threads (servlet spec) and avoids to be forced to > use message passing which - even if a good pattern - adds boilerplate > code for simple async needs. > > For JAXRS I dont know since it is really suspend/resume semantic so > request scope maybe doesnt makes much sense here (there is a break in > the flow). > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand >: > > Hi All, > > > > Beyond the asynchronous event case, shouldn?t we provide a way for user > to launch async treatments in CDI with the possibility to keep the existing > contexts at the moment of async operation launch? > > Today servlet or JAX-RS spec support async call without the loss of > request for instance. Shouldn?t we think to something like that? > > > > Thanks for your input on that point. > > > > 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. > > _______________________________________________ > 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/20150219/89fb6767/attachment-0001.html From struberg at yahoo.de Thu Feb 19 11:40:34 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 17:40:34 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: Even in Servlets-3.0 a ?Request? is only attached to exactly one single thread AT THE SAME TIME afaik. So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand. LieGrue, strub > Am 19.02.2015 um 17:33 schrieb Sven Linstaedt : > > Hi, > > and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: > > 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". > > 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded. > > 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization. > > 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe. > > > Best regards > Sven > > 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : > Hi > > I'm +1 for it but it needs important changes (= surely new contexts). > Typically we can't change today @RequestScoped (which has no link with > a request but only with a thread!). > > So we could have @RequestScoped (~ @ThreadLocalScoped) and > @InheritedRequestScoped which would be a real request scope (but not > an InheritedThreadLocal please) > > For the request it makes a lot of sense since you need to stay thread > safe even accross threads (servlet spec) and avoids to be forced to > use message passing which - even if a good pattern - adds boilerplate > code for simple async needs. > > For JAXRS I dont know since it is really suspend/resume semantic so > request scope maybe doesnt makes much sense here (there is a break in > the flow). > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand : > > Hi All, > > > > Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? > > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? > > > > Thanks for your input on that point. > > > > 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. > > _______________________________________________ > 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 Thu Feb 19 11:52:02 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 17:52:02 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: @Mark: for the container usage only but nothing prevents you to use it elsewhere at your own risk Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 17:40 GMT+01:00 Mark Struberg : > Even in Servlets-3.0 a ?Request? is only attached to exactly one single thread AT THE SAME TIME afaik. > > So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand. > > LieGrue, > strub > > >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt : >> >> Hi, >> >> and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: >> >> 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". >> >> 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded. >> >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization. >> >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe. >> >> >> Best regards >> Sven >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : >> Hi >> >> I'm +1 for it but it needs important changes (= surely new contexts). >> Typically we can't change today @RequestScoped (which has no link with >> a request but only with a thread!). >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and >> @InheritedRequestScoped which would be a real request scope (but not >> an InheritedThreadLocal please) >> >> For the request it makes a lot of sense since you need to stay thread >> safe even accross threads (servlet spec) and avoids to be forced to >> use message passing which - even if a good pattern - adds boilerplate >> code for simple async needs. >> >> For JAXRS I dont know since it is really suspend/resume semantic so >> request scope maybe doesnt makes much sense here (there is a break in >> the flow). >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand : >> > Hi All, >> > >> > Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? >> > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? >> > >> > Thanks for your input on that point. >> > >> > 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. >> >> _______________________________________________ >> 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. > > > _______________________________________________ > 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 jharting at redhat.com Thu Feb 19 11:59:16 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Feb 2015 17:59:16 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: <54E61664.9060004@redhat.com> +1 On 02/19/2015 05:40 PM, Mark Struberg wrote: > Even in Servlets-3.0 a ?Request? is only attached to exactly one single thread AT THE SAME TIME afaik. > > So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand. > > LieGrue, > strub > > >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt : >> >> Hi, >> >> and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: >> >> 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". >> >> 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded. >> >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization. >> >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe. >> >> >> Best regards >> Sven >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : >> Hi >> >> I'm +1 for it but it needs important changes (= surely new contexts). >> Typically we can't change today @RequestScoped (which has no link with >> a request but only with a thread!). >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and >> @InheritedRequestScoped which would be a real request scope (but not >> an InheritedThreadLocal please) >> >> For the request it makes a lot of sense since you need to stay thread >> safe even accross threads (servlet spec) and avoids to be forced to >> use message passing which - even if a good pattern - adds boilerplate >> code for simple async needs. >> >> For JAXRS I dont know since it is really suspend/resume semantic so >> request scope maybe doesnt makes much sense here (there is a break in >> the flow). >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand : >>> Hi All, >>> >>> Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? >>> Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? >>> >>> Thanks for your input on that point. >>> >>> 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. >> _______________________________________________ >> 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. > > _______________________________________________ > 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 sven.linstaedt at gmail.com Thu Feb 19 12:13:39 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 19 Feb 2015 18:13:39 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: The question remains: Does CDI has to make sure, request scope implies single threaded access, because most existing applications are not aware of possible threading issues for request scoped beans? I do not think so. Afaik the same problem has affected session scoped beans before servlet 3.0, but application developers are hopefully more aware of it. 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : > @Mark: for the container usage only but nothing prevents you to use it > elsewhere at your own risk > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 17:40 GMT+01:00 Mark Struberg : > > Even in Servlets-3.0 a ?Request? is only attached to exactly one single > thread AT THE SAME TIME afaik. > > > > So they can switch a Request from one thread to another one, but there > is always just a single one accessing it at the same time. At least that is > what I did understand. > > > > LieGrue, > > strub > > > > > >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt >: > >> > >> Hi, > >> > >> and sorry for spontaneously dropping in. Just to clarify some personal > questions/assumptions: > >> > >> 1. Regarding threading the current spec only states that "A context may > be associated with one or more threads". > >> > >> 2. It is nowhere stated that @RequestScoped beans are inherently thread > safe. Thread safety was implied from the servlet spec, because the scope > backing container (ServletRequest#attributes) was executed single threaded. > >> > >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for > access from multiple threads via ServletRequest#startAsync(), so > containing objects may have a need for synchronization. > >> > >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped > beans? If the application is for some reason setting the request in async > mode, the application must also ensure, it's containing and accessed beans > are thread safe. > >> > >> > >> Best regards > >> Sven > >> > >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : > >> Hi > >> > >> I'm +1 for it but it needs important changes (= surely new contexts). > >> Typically we can't change today @RequestScoped (which has no link with > >> a request but only with a thread!). > >> > >> So we could have @RequestScoped (~ @ThreadLocalScoped) and > >> @InheritedRequestScoped which would be a real request scope (but not > >> an InheritedThreadLocal please) > >> > >> For the request it makes a lot of sense since you need to stay thread > >> safe even accross threads (servlet spec) and avoids to be forced to > >> use message passing which - even if a good pattern - adds boilerplate > >> code for simple async needs. > >> > >> For JAXRS I dont know since it is really suspend/resume semantic so > >> request scope maybe doesnt makes much sense here (there is a break in > >> the flow). > >> > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >> > Hi All, > >> > > >> > Beyond the asynchronous event case, shouldn?t we provide a way for > user to launch async treatments in CDI with the possibility to keep the > existing contexts at the moment of async operation launch? > >> > Today servlet or JAX-RS spec support async call without the loss of > request for instance. Shouldn?t we think to something like that? > >> > > >> > Thanks for your input on that point. > >> > > >> > 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. > >> > >> _______________________________________________ > >> 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. > > > > > > _______________________________________________ > > 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/20150219/338db529/attachment-0001.html From rmannibucau at gmail.com Thu Feb 19 12:18:16 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 18:18:16 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: today request scope = thread scope and we can't help on it. I recall having said web scopes should stay aligned on web behavior but answer was quite clear: this is not what is in the spec (at least in intention term) which is fine but today request scope is also used in batches for thread scope behaviors so too late to change. Servlet spec can have its own web scope now which would allow to fix this and go ahead. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 18:13 GMT+01:00 Sven Linstaedt : > The question remains: Does CDI has to make sure, request scope implies > single threaded access, because most existing applications are not aware of > possible threading issues for request scoped beans? > > I do not think so. Afaik the same problem has affected session scoped beans > before servlet 3.0, but application developers are hopefully more aware of > it. > > 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : >> >> @Mark: for the container usage only but nothing prevents you to use it >> elsewhere at your own risk >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 17:40 GMT+01:00 Mark Struberg : >> > Even in Servlets-3.0 a ?Request? is only attached to exactly one single >> > thread AT THE SAME TIME afaik. >> > >> > So they can switch a Request from one thread to another one, but there >> > is always just a single one accessing it at the same time. At least that is >> > what I did understand. >> > >> > LieGrue, >> > strub >> > >> > >> >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt >> >> : >> >> >> >> Hi, >> >> >> >> and sorry for spontaneously dropping in. Just to clarify some personal >> >> questions/assumptions: >> >> >> >> 1. Regarding threading the current spec only states that "A context may >> >> be associated with one or more threads". >> >> >> >> 2. It is nowhere stated that @RequestScoped beans are inherently thread >> >> safe. Thread safety was implied from the servlet spec, because the scope >> >> backing container (ServletRequest#attributes) was executed single threaded. >> >> >> >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for >> >> access from multiple threads via ServletRequest#startAsync(), so containing >> >> objects may have a need for synchronization. >> >> >> >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped >> >> beans? If the application is for some reason setting the request in async >> >> mode, the application must also ensure, it's containing and accessed beans >> >> are thread safe. >> >> >> >> >> >> Best regards >> >> Sven >> >> >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : >> >> Hi >> >> >> >> I'm +1 for it but it needs important changes (= surely new contexts). >> >> Typically we can't change today @RequestScoped (which has no link with >> >> a request but only with a thread!). >> >> >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and >> >> @InheritedRequestScoped which would be a real request scope (but not >> >> an InheritedThreadLocal please) >> >> >> >> For the request it makes a lot of sense since you need to stay thread >> >> safe even accross threads (servlet spec) and avoids to be forced to >> >> use message passing which - even if a good pattern - adds boilerplate >> >> code for simple async needs. >> >> >> >> For JAXRS I dont know since it is really suspend/resume semantic so >> >> request scope maybe doesnt makes much sense here (there is a break in >> >> the flow). >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand >> >> : >> >> > Hi All, >> >> > >> >> > Beyond the asynchronous event case, shouldn?t we provide a way for >> >> > user to launch async treatments in CDI with the possibility to keep the >> >> > existing contexts at the moment of async operation launch? >> >> > Today servlet or JAX-RS spec support async call without the loss of >> >> > request for instance. Shouldn?t we think to something like that? >> >> > >> >> > Thanks for your input on that point. >> >> > >> >> > 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. >> >> >> >> _______________________________________________ >> >> 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. >> > >> > >> > _______________________________________________ >> > 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 sven.linstaedt at gmail.com Thu Feb 19 12:44:18 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 19 Feb 2015 18:44:18 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: Okay, so request scope is not associated with web requests, but with "invocation chains". I thought so because session scope is associated with web requests and Weld is backing it's request scope implementation with request attributes. So the SPI has a need for dispatching async work in new threads, at it's best with most common scopes (application, session and request) being active? Application does not seem to be a problem. Request is always a new context per thread. The question is, whether session scope is propagated to newly spawned threads, when using this SPI? Afaik it's currently only active during web requests. From an implementation point of view it could be tricky to disassociate current session scope impls from servlet session lifecycle. On the other side: from a user point of view it would be nice, if I dispatch work via some SPI, the processing of work is done in the same "user context". 2015-02-19 18:18 GMT+01:00 Romain Manni-Bucau : > today request scope = thread scope and we can't help on it. I recall > having said web scopes should stay aligned on web behavior but answer > was quite clear: this is not what is in the spec (at least in > intention term) which is fine but today request scope is also used in > batches for thread scope behaviors so too late to change. Servlet spec > can have its own web scope now which would allow to fix this and go > ahead. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 18:13 GMT+01:00 Sven Linstaedt : > > The question remains: Does CDI has to make sure, request scope implies > > single threaded access, because most existing applications are not aware > of > > possible threading issues for request scoped beans? > > > > I do not think so. Afaik the same problem has affected session scoped > beans > > before servlet 3.0, but application developers are hopefully more aware > of > > it. > > > > 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : > >> > >> @Mark: for the container usage only but nothing prevents you to use it > >> elsewhere at your own risk > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-19 17:40 GMT+01:00 Mark Struberg : > >> > Even in Servlets-3.0 a ?Request? is only attached to exactly one > single > >> > thread AT THE SAME TIME afaik. > >> > > >> > So they can switch a Request from one thread to another one, but there > >> > is always just a single one accessing it at the same time. At least > that is > >> > what I did understand. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt > >> >> : > >> >> > >> >> Hi, > >> >> > >> >> and sorry for spontaneously dropping in. Just to clarify some > personal > >> >> questions/assumptions: > >> >> > >> >> 1. Regarding threading the current spec only states that "A context > may > >> >> be associated with one or more threads". > >> >> > >> >> 2. It is nowhere stated that @RequestScoped beans are inherently > thread > >> >> safe. Thread safety was implied from the servlet spec, because the > scope > >> >> backing container (ServletRequest#attributes) was executed single > threaded. > >> >> > >> >> 3. With Servlet 3.0 the same ServletRequest#attributes is available > for > >> >> access from multiple threads via ServletRequest#startAsync(), so > containing > >> >> objects may have a need for synchronization. > >> >> > >> >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped > >> >> beans? If the application is for some reason setting the request in > async > >> >> mode, the application must also ensure, it's containing and accessed > beans > >> >> are thread safe. > >> >> > >> >> > >> >> Best regards > >> >> Sven > >> >> > >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau >: > >> >> Hi > >> >> > >> >> I'm +1 for it but it needs important changes (= surely new contexts). > >> >> Typically we can't change today @RequestScoped (which has no link > with > >> >> a request but only with a thread!). > >> >> > >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and > >> >> @InheritedRequestScoped which would be a real request scope (but not > >> >> an InheritedThreadLocal please) > >> >> > >> >> For the request it makes a lot of sense since you need to stay thread > >> >> safe even accross threads (servlet spec) and avoids to be forced to > >> >> use message passing which - even if a good pattern - adds boilerplate > >> >> code for simple async needs. > >> >> > >> >> For JAXRS I dont know since it is really suspend/resume semantic so > >> >> request scope maybe doesnt makes much sense here (there is a break in > >> >> the flow). > >> >> > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand > >> >> : > >> >> > Hi All, > >> >> > > >> >> > Beyond the asynchronous event case, shouldn?t we provide a way for > >> >> > user to launch async treatments in CDI with the possibility to > keep the > >> >> > existing contexts at the moment of async operation launch? > >> >> > Today servlet or JAX-RS spec support async call without the loss of > >> >> > request for instance. Shouldn?t we think to something like that? > >> >> > > >> >> > Thanks for your input on that point. > >> >> > > >> >> > 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. > >> >> > >> >> _______________________________________________ > >> >> 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. > >> > > >> > > >> > _______________________________________________ > >> > 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/20150219/54849e6e/attachment-0001.html From struberg at yahoo.de Thu Feb 19 12:48:10 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 18:48:10 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: <3FFAC8C9-4A80-4728-851E-E53387180390@yahoo.de> Hi Sven! I don?t get the comparison with the Session. Attributes stored in the Session can get modified in parallel Servlet Requests since day 1 of the Servet specification. They also effectively almost always get handled by a different Thread for each subsequent Request. So thise objects must implement proper concurrency handling since forever. This is not changed by the fact that a lot of developers seem to not be aware of it. LieGrue, strub > Am 19.02.2015 um 18:13 schrieb Sven Linstaedt : > > The question remains: Does CDI has to make sure, request scope implies single threaded access, because most existing applications are not aware of possible threading issues for request scoped beans? > > I do not think so. Afaik the same problem has affected session scoped beans before servlet 3.0, but application developers are hopefully more aware of it. > > 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : > @Mark: for the container usage only but nothing prevents you to use it > elsewhere at your own risk > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 17:40 GMT+01:00 Mark Struberg : > > Even in Servlets-3.0 a ?Request? is only attached to exactly one single thread AT THE SAME TIME afaik. > > > > So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand. > > > > LieGrue, > > strub > > > > > >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt : > >> > >> Hi, > >> > >> and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: > >> > >> 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". > >> > >> 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded. > >> > >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization. > >> > >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe. > >> > >> > >> Best regards > >> Sven > >> > >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : > >> Hi > >> > >> I'm +1 for it but it needs important changes (= surely new contexts). > >> Typically we can't change today @RequestScoped (which has no link with > >> a request but only with a thread!). > >> > >> So we could have @RequestScoped (~ @ThreadLocalScoped) and > >> @InheritedRequestScoped which would be a real request scope (but not > >> an InheritedThreadLocal please) > >> > >> For the request it makes a lot of sense since you need to stay thread > >> safe even accross threads (servlet spec) and avoids to be forced to > >> use message passing which - even if a good pattern - adds boilerplate > >> code for simple async needs. > >> > >> For JAXRS I dont know since it is really suspend/resume semantic so > >> request scope maybe doesnt makes much sense here (there is a break in > >> the flow). > >> > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand : > >> > Hi All, > >> > > >> > Beyond the asynchronous event case, shouldn?t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch? > >> > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn?t we think to something like that? > >> > > >> > Thanks for your input on that point. > >> > > >> > 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. > >> > >> _______________________________________________ > >> 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. > > > > > > _______________________________________________ > > 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 struberg at yahoo.de Thu Feb 19 12:55:17 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 18:55:17 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: > Okay, so request scope is not associated with web requests, but with ?invocation chains". Yes. E.g. the Context for RequestScoped beans has to be active for invocations of @Asynchronous methods, MessageBean invocations, @PostConstruct and @PreDestroy methods of all Managed Beans, @WebService invocations, etc > whether session scope is propagated to newly spawned threads We can look at javax.ejb.Asynchronous. Invocations to those methods will get a new Request Context but there will be no SessionContext for them (which Session would you attach to this thread? It could also be a long-running one?). LieGrue, strub > Am 19.02.2015 um 18:44 schrieb Sven Linstaedt : > > Okay, so request scope is not associated with web requests, but with "invocation chains". I thought so because session scope is associated with web requests and Weld is backing it's request scope implementation with request attributes. > > So the SPI has a need for dispatching async work in new threads, at it's best with most common scopes (application, session and request) being active? > > Application does not seem to be a problem. Request is always a new context per thread. The question is, whether session scope is propagated to newly spawned threads, when using this SPI? Afaik it's currently only active during web requests. From an implementation point of view it could be tricky to disassociate current session scope impls from servlet session lifecycle. On the other side: from a user point of view it would be nice, if I dispatch work via some SPI, the processing of work is done in the same "user context". > > > > 2015-02-19 18:18 GMT+01:00 Romain Manni-Bucau : > today request scope = thread scope and we can't help on it. I recall > having said web scopes should stay aligned on web behavior but answer > was quite clear: this is not what is in the spec (at least in > intention term) which is fine but today request scope is also used in > batches for thread scope behaviors so too late to change. Servlet spec > can have its own web scope now which would allow to fix this and go > ahead. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 18:13 GMT+01:00 Sven Linstaedt : > > The question remains: Does CDI has to make sure, request scope implies > > single threaded access, because most existing applications are not aware of > > possible threading issues for request scoped beans? > > > > I do not think so. Afaik the same problem has affected session scoped beans > > before servlet 3.0, but application developers are hopefully more aware of > > it. > > > > 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : > >> > >> @Mark: for the container usage only but nothing prevents you to use it > >> elsewhere at your own risk > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-02-19 17:40 GMT+01:00 Mark Struberg : > >> > Even in Servlets-3.0 a ?Request? is only attached to exactly one single > >> > thread AT THE SAME TIME afaik. > >> > > >> > So they can switch a Request from one thread to another one, but there > >> > is always just a single one accessing it at the same time. At least that is > >> > what I did understand. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt > >> >> : > >> >> > >> >> Hi, > >> >> > >> >> and sorry for spontaneously dropping in. Just to clarify some personal > >> >> questions/assumptions: > >> >> > >> >> 1. Regarding threading the current spec only states that "A context may > >> >> be associated with one or more threads". > >> >> > >> >> 2. It is nowhere stated that @RequestScoped beans are inherently thread > >> >> safe. Thread safety was implied from the servlet spec, because the scope > >> >> backing container (ServletRequest#attributes) was executed single threaded. > >> >> > >> >> 3. With Servlet 3.0 the same ServletRequest#attributes is available for > >> >> access from multiple threads via ServletRequest#startAsync(), so containing > >> >> objects may have a need for synchronization. > >> >> > >> >> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped > >> >> beans? If the application is for some reason setting the request in async > >> >> mode, the application must also ensure, it's containing and accessed beans > >> >> are thread safe. > >> >> > >> >> > >> >> Best regards > >> >> Sven > >> >> > >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : > >> >> Hi > >> >> > >> >> I'm +1 for it but it needs important changes (= surely new contexts). > >> >> Typically we can't change today @RequestScoped (which has no link with > >> >> a request but only with a thread!). > >> >> > >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and > >> >> @InheritedRequestScoped which would be a real request scope (but not > >> >> an InheritedThreadLocal please) > >> >> > >> >> For the request it makes a lot of sense since you need to stay thread > >> >> safe even accross threads (servlet spec) and avoids to be forced to > >> >> use message passing which - even if a good pattern - adds boilerplate > >> >> code for simple async needs. > >> >> > >> >> For JAXRS I dont know since it is really suspend/resume semantic so > >> >> request scope maybe doesnt makes much sense here (there is a break in > >> >> the flow). > >> >> > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand > >> >> : > >> >> > Hi All, > >> >> > > >> >> > Beyond the asynchronous event case, shouldn?t we provide a way for > >> >> > user to launch async treatments in CDI with the possibility to keep the > >> >> > existing contexts at the moment of async operation launch? > >> >> > Today servlet or JAX-RS spec support async call without the loss of > >> >> > request for instance. Shouldn?t we think to something like that? > >> >> > > >> >> > Thanks for your input on that point. > >> >> > > >> >> > 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. > >> >> > >> >> _______________________________________________ > >> >> 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. > >> > > >> > > >> > _______________________________________________ > >> > 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 antoine at sabot-durand.net Thu Feb 19 12:56:43 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Feb 2015 18:56:43 +0100 Subject: [cdi-dev] Meet our new ambassador In-Reply-To: <5FC03086-3F1D-42DA-BCEB-52907B42CD2B@redhat.com> References: <559D9756-82CB-451F-9D2D-A1DCD9246854@sabot-durand.net> <5FC03086-3F1D-42DA-BCEB-52907B42CD2B@redhat.com> Message-ID: <20811EED-FF1A-4262-86F0-C0EF47DFA925@sabot-durand.net> After legal check. These elements are under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0). so more concretely the details are: ? Share ? copy and redistribute the material in any medium or format ? The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: ? Attribution ? You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. ? NonCommercial ? You may not use the material for commercial purposes. ? NoDerivatives ? If you remix, transform, or build upon the material, you may not distribute the modified material. ? No additional restrictions ? You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. Antoine > Le 19 f?vr. 2015 ? 16:20, Pete Muir a ?crit : > > We are looking in to this, stay tuned :-) > >> On 19 Feb 2015, at 11:45, Thorben Janssen > wrote: >> >> Hi Antoine, >> >> under which license are the images licensed? >> I was told, that most of the JBoss related logos (in that specific case Arquillian) are licensed under a closed one. If that is also the case for the CDI logo, we should better not use it for any social media post or article that is not published on the CDI website. >> >> Regards, >> Thorben >> >> -- >> Thorben Janssen >> >> @thjanssen123 >> www.thoughts-on-java.org >> >> 2015-02-19 11:04 GMT+01:00 Antoine Sabot-Durand >: >> Hi All, >> >> >> With the idea to increase CDI notoriety we ask JBoss design team to work on CDI Logo. Creating an identity for something as abstract as CDI is not very easy so we asked the design team to avoid corporate logo and give a true identity to CDI thru a mascot. >> So meet our new ambassador and logo : >> >> >> I have a bunch of graphic elements (http://design.jboss.org/cdi/index.htm ) to switch our look and feel on the web and on social network. We?re even ready to have T-Shirts and other swag that can be ordered here: >> >> http://www.cafepress.com/jbossorg/12231128 >> >> These stuff will make nice giveaways for conferences to help creating a CDI brand and raise the adoption of the spec. >> >> Now, this bearded fellow has still no name. Cildmi was the first name to come to my mind, but perhaps you have better ideas? >> >> Regards, >> >> 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. >> >> _______________________________________________ >> 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/20150219/c28762ac/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/c28762ac/attachment-0001.bin From werner.keil at gmail.com Thu Feb 19 13:05:25 2015 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 19 Feb 2015 19:05:25 +0100 Subject: [cdi-dev] Meet our new ambassador Message-ID: Aside from the image, whatever name he ends up with, given the whole Arquillian project heavily (and directly) borrows from a well known movie franchise, should there be at least an "inspiration" for his name from another, it looks like we're safe there, too?;-) Werner On Thu, Feb 19, 2015 at 6:56 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. Re: Enhancing SPI to support async operation for contexts > (Mark Struberg) > 2. Re: Enhancing SPI to support async operation for contexts > (Mark Struberg) > 3. Re: Meet our new ambassador (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > > Message: 3 > Date: Thu, 19 Feb 2015 18:56:43 +0100 > From: Antoine Sabot-Durand > Subject: Re: [cdi-dev] Meet our new ambassador > To: Pete Muir > Cc: cdi-dev > Message-ID: <20811EED-FF1A-4262-86F0-C0EF47DFA925 at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > After legal check. These elements are under Creative Commons > Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0). > > so more concretely the details are: > > ? Share ? copy and redistribute the material in any medium or format > ? The licensor cannot revoke these freedoms as long as you follow the > license terms. > > Under the following terms: > > ? Attribution ? You must give appropriate credit, provide a link to the > license, and indicate if changes were made. You may do so in any reasonable > manner, but not in any way that suggests the licensor endorses you or your > use. > ? NonCommercial ? You may not use the material for commercial purposes. > ? NoDerivatives ? If you remix, transform, or build upon the material, you > may not distribute the modified material. > ? No additional restrictions ? You may not apply legal terms or > technological measures that legally restrict others from doing anything the > license permits. > > > Antoine > > > Le 19 f?vr. 2015 ? 16:20, Pete Muir a ?crit : > > > > We are looking in to this, stay tuned :-) > > > >> On 19 Feb 2015, at 11:45, Thorben Janssen > wrote: > >> > >> Hi Antoine, > >> > >> under which license are the images licensed? > >> I was told, that most of the JBoss related logos (in that specific case > Arquillian) are licensed under a closed one. If that is also the case for > the CDI logo, we should better not use it for any social media post or > article that is not published on the CDI website. > >> > >> Regards, > >> Thorben > >> > >> -- > >> Thorben Janssen > >> > >> @thjanssen123 > >> www.thoughts-on-java.org > >> > >> 2015-02-19 11:04 GMT+01:00 Antoine Sabot-Durand < > antoine at sabot-durand.net >: > >> Hi All, > >> > >> > >> With the idea to increase CDI notoriety we ask JBoss design team to > work on CDI Logo. Creating an identity for something as abstract as CDI is > not very easy so we asked the design team to avoid corporate logo and give > a true identity to CDI thru a mascot. > >> So meet our new ambassador and logo : > >> > >> > >> I have a bunch of graphic elements ( > http://design.jboss.org/cdi/index.htm < > http://design.jboss.org/cdi/index.htm>) to switch our look and feel on > the web and on social network. We?re even ready to have T-Shirts and other > swag that can be ordered here: > >> > >> http://www.cafepress.com/jbossorg/12231128 < > http://www.cafepress.com/jbossorg/12231128> > >> > >> These stuff will make nice giveaways for conferences to help creating a > CDI brand and raise the adoption of the spec. > >> > >> Now, this bearded fellow has still no name. Cildmi was the first name > to come to my mind, but perhaps you have better ideas? > >> > >> Regards, > >> > >> Antoine > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev < > 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 < > 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 < > 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 < > 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/20150219/c28762ac/attachment.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/c28762ac/attachment.bin > > ------------------------------ > > _______________________________________________ > 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 51, Issue 36 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/0dd55ea0/attachment.html From sven.linstaedt at gmail.com Thu Feb 19 14:18:25 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 19 Feb 2015 20:18:25 +0100 Subject: [cdi-dev] Enhancing SPI to support async operation for contexts In-Reply-To: References: Message-ID: <2C5FC9D5-D4CA-443E-BF9C-F09DFEE0DE78@gmail.com> As an application developer being able to programmatically dispatch async tasks using some cdi api, I would expect the dispatched threads sharing the dispatcher's thread session, respectively the session scope from the dispatcher's thread being propagated to the tasks/event/job processing threads. If the term "request context" is associated with single execution threads, I would associate "session context" with something, that is propagated to newly request, especially if I was the one, who directly or indirectly caused them. Am 19.02.2015 um 18:55 schrieb Mark Struberg : >> Okay, so request scope is not associated with web requests, but with ?invocation chains". > > Yes. E.g. the Context for RequestScoped beans has to be active for invocations of @Asynchronous methods, MessageBean invocations, @PostConstruct and @PreDestroy methods of all Managed Beans, @WebService invocations, etc > > >> whether session scope is propagated to newly spawned threads > > We can look at javax.ejb.Asynchronous. Invocations to those methods will get a new Request Context but there will be no SessionContext for them (which Session would you attach to this thread? It could also be a long-running one?). > > > LieGrue, > strub > > >> Am 19.02.2015 um 18:44 schrieb Sven Linstaedt : >> >> Okay, so request scope is not associated with web requests, but with "invocation chains". I thought so because session scope is associated with web requests and Weld is backing it's request scope implementation with request attributes. >> >> So the SPI has a need for dispatching async work in new threads, at it's best with most common scopes (application, session and request) being active? >> >> Application does not seem to be a problem. Request is always a new context per thread. The question is, whether session scope is propagated to newly spawned threads, when using this SPI? Afaik it's currently only active during web requests. From an implementation point of view it could be tricky to disassociate current session scope impls from servlet session lifecycle. On the other side: from a user point of view it would be nice, if I dispatch work via some SPI, the processing of work is done in the same "user context". >> >> >> >> 2015-02-19 18:18 GMT+01:00 Romain Manni-Bucau : >> today request scope = thread scope and we can't help on it. I recall >> having said web scopes should stay aligned on web behavior but answer >> was quite clear: this is not what is in the spec (at least in >> intention term) which is fine but today request scope is also used in >> batches for thread scope behaviors so too late to change. Servlet spec >> can have its own web scope now which would allow to fix this and go >> ahead. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 18:13 GMT+01:00 Sven Linstaedt : >>> The question remains: Does CDI has to make sure, request scope implies >>> single threaded access, because most existing applications are not aware of >>> possible threading issues for request scoped beans? >>> >>> I do not think so. Afaik the same problem has affected session scoped beans >>> before servlet 3.0, but application developers are hopefully more aware of >>> it. >>> >>> 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau : >>>> >>>> @Mark: for the container usage only but nothing prevents you to use it >>>> elsewhere at your own risk >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-19 17:40 GMT+01:00 Mark Struberg : >>>>> Even in Servlets-3.0 a ?Request? is only attached to exactly one single >>>>> thread AT THE SAME TIME afaik. >>>>> >>>>> So they can switch a Request from one thread to another one, but there >>>>> is always just a single one accessing it at the same time. At least that is >>>>> what I did understand. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>>> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt >>>>>> : >>>>>> >>>>>> Hi, >>>>>> >>>>>> and sorry for spontaneously dropping in. Just to clarify some personal >>>>>> questions/assumptions: >>>>>> >>>>>> 1. Regarding threading the current spec only states that "A context may >>>>>> be associated with one or more threads". >>>>>> >>>>>> 2. It is nowhere stated that @RequestScoped beans are inherently thread >>>>>> safe. Thread safety was implied from the servlet spec, because the scope >>>>>> backing container (ServletRequest#attributes) was executed single threaded. >>>>>> >>>>>> 3. With Servlet 3.0 the same ServletRequest#attributes is available for >>>>>> access from multiple threads via ServletRequest#startAsync(), so containing >>>>>> objects may have a need for synchronization. >>>>>> >>>>>> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped >>>>>> beans? If the application is for some reason setting the request in async >>>>>> mode, the application must also ensure, it's containing and accessed beans >>>>>> are thread safe. >>>>>> >>>>>> >>>>>> Best regards >>>>>> Sven >>>>>> >>>>>> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau : >>>>>> Hi >>>>>> >>>>>> I'm +1 for it but it needs important changes (= surely new contexts). >>>>>> Typically we can't change today @RequestScoped (which has no link with >>>>>> a request but only with a thread!). >>>>>> >>>>>> So we could have @RequestScoped (~ @ThreadLocalScoped) and >>>>>> @InheritedRequestScoped which would be a real request scope (but not >>>>>> an InheritedThreadLocal please) >>>>>> >>>>>> For the request it makes a lot of sense since you need to stay thread >>>>>> safe even accross threads (servlet spec) and avoids to be forced to >>>>>> use message passing which - even if a good pattern - adds boilerplate >>>>>> code for simple async needs. >>>>>> >>>>>> For JAXRS I dont know since it is really suspend/resume semantic so >>>>>> request scope maybe doesnt makes much sense here (there is a break in >>>>>> the flow). >>>>>> >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand >>>>>> : >>>>>>> Hi All, >>>>>>> >>>>>>> Beyond the asynchronous event case, shouldn?t we provide a way for >>>>>>> user to launch async treatments in CDI with the possibility to keep the >>>>>>> existing contexts at the moment of async operation launch? >>>>>>> Today servlet or JAX-RS spec support async call without the loss of >>>>>>> request for instance. Shouldn?t we think to something like that? >>>>>>> >>>>>>> Thanks for your input on that point. >>>>>>> >>>>>>> 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. >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 struberg at yahoo.de Thu Feb 19 14:54:18 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 20:54:18 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E606F5.2030207@redhat.com> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> Message-ID: <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> > if you fire(new Object()) in war1, nothing prevents > it from being delivered also in war2 / ejb jars That must not happen. Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. LieGrue, strub > Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : > > On 02/19/2015 03:21 PM, Mark Struberg wrote: >> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >> >> And as expected it is pretty much non-portable (to avoid the word ?broken?). >> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >> >> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? > Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >> >> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >> >> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >> >> LieGrue, >> strub >> >> >> >>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>> >>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>> >>> A - in a shared jar >>> B - in a war >>> >>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>> >>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>> >>> So far we'll hopefully on the same page. >>> >>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>> >>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>> >>> ABean - is injectable into beans anywhere in the entire EAR >>> BBean - is not injectable outside of the given war >>> >>> HTH, >>> >>> Jozef >>> >>> >>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>> >>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>> So we have 4 cases to look at. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>> >>>>> What are the bean classes of those additional beans? >>>>> >>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>> Again, just trying to understand how it works in Weld. >>>>>> >>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>> >>>>>> We have an >>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>> in a shared ear lib jar and a second one >>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>> in WEB-INF/classes of war1. >>>>>> >>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>> >>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>> >>>>>> Questions: >>>>>> Q1: Which BeanManager do I get here? >>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>> >>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>> >>>>>> >>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>> >>>>>>> >>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>> >>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>> >>>>>>>> >>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>> >>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>> Interesting write up! >>>>>>>>> >>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>> >>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>> and ears from our perspective here: >>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Arjan Tijms >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>> >>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Thu Feb 19 14:56:15 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 20:56:15 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: Agree, the most logical + understandable (=usable) rule is to be aligned to classloading/structure. Breaking this simple rule completely breaks the common usage Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 20:54 GMT+01:00 Mark Struberg : >> if you fire(new Object()) in war1, nothing prevents >> it from being delivered also in war2 / ejb jars > > That must not happen. > > Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. > > > Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. > > I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. > > LieGrue, > strub > > > >> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >> >> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>> >>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>> >>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>> >>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>> >>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>> >>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>> >>>> A - in a shared jar >>>> B - in a war >>>> >>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>> >>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>> >>>> So far we'll hopefully on the same page. >>>> >>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>> >>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>> >>>> ABean - is injectable into beans anywhere in the entire EAR >>>> BBean - is not injectable outside of the given war >>>> >>>> HTH, >>>> >>>> Jozef >>>> >>>> >>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>> >>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>> So we have 4 cases to look at. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>> >>>>>> What are the bean classes of those additional beans? >>>>>> >>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>> Again, just trying to understand how it works in Weld. >>>>>>> >>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>> >>>>>>> We have an >>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>> in a shared ear lib jar and a second one >>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>> in WEB-INF/classes of war1. >>>>>>> >>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>> >>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>> >>>>>>> Questions: >>>>>>> Q1: Which BeanManager do I get here? >>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>> >>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>> >>>>>>>> >>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>> >>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>> >>>>>>>>> >>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>> >>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>> Interesting write up! >>>>>>>>>> >>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>> >>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>> and ears from our perspective here: >>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Arjan Tijms >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>> >>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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. >> > > > _______________________________________________ > 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 struberg at yahoo.de Thu Feb 19 15:10:47 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Feb 2015 21:10:47 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: +1 It?s not only logical, it?s really technically crucial. Say in war1 you call beanManager.fire(new ClassWhichOnlyExistsInWar1()); and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. That?s broken, broken, broken. LieGrue, strub > Am 19.02.2015 um 20:56 schrieb Romain Manni-Bucau : > > Agree, the most logical + understandable (=usable) rule is to be > aligned to classloading/structure. Breaking this simple rule > completely breaks the common usage > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 20:54 GMT+01:00 Mark Struberg : >>> if you fire(new Object()) in war1, nothing prevents >>> it from being delivered also in war2 / ejb jars >> >> That must not happen. >> >> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >> >> >> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. >> >> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >> >> LieGrue, >> strub >> >> >> >>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>> >>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>> >>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>> >>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>> >>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>> >>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>> >>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>> >>>>> A - in a shared jar >>>>> B - in a war >>>>> >>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>> >>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>> >>>>> So far we'll hopefully on the same page. >>>>> >>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>> >>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>> >>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>> BBean - is not injectable outside of the given war >>>>> >>>>> HTH, >>>>> >>>>> Jozef >>>>> >>>>> >>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>> >>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>> So we have 4 cases to look at. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>> >>>>>>> What are the bean classes of those additional beans? >>>>>>> >>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>> >>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>> >>>>>>>> We have an >>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>> in a shared ear lib jar and a second one >>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>> in WEB-INF/classes of war1. >>>>>>>> >>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>> >>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>> >>>>>>>> Questions: >>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>> >>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>> >>>>>>>> >>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>> >>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>> >>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>> Interesting write up! >>>>>>>>>>> >>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>> >>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Arjan Tijms >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>> >>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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. >>> >> >> >> _______________________________________________ >> 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 Thu Feb 19 16:28:13 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Feb 2015 22:28:13 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: yep what's I meant by logical (technically we an do all we want) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 21:10 GMT+01:00 Mark Struberg : > +1 > It?s not only logical, it?s really technically crucial. > > Say in war1 you call > > beanManager.fire(new ClassWhichOnlyExistsInWar1()); > > and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. > That?s broken, broken, broken. > > LieGrue, > strub > > >> Am 19.02.2015 um 20:56 schrieb Romain Manni-Bucau : >> >> Agree, the most logical + understandable (=usable) rule is to be >> aligned to classloading/structure. Breaking this simple rule >> completely breaks the common usage >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 20:54 GMT+01:00 Mark Struberg : >>>> if you fire(new Object()) in war1, nothing prevents >>>> it from being delivered also in war2 / ejb jars >>> >>> That must not happen. >>> >>> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >>> >>> >>> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. >>> >>> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>>> >>>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>>> >>>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>>> >>>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>>> >>>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>>> >>>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>>> >>>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>>> >>>>>> A - in a shared jar >>>>>> B - in a war >>>>>> >>>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>>> >>>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>>> >>>>>> So far we'll hopefully on the same page. >>>>>> >>>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>>> >>>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>>> >>>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>>> BBean - is not injectable outside of the given war >>>>>> >>>>>> HTH, >>>>>> >>>>>> Jozef >>>>>> >>>>>> >>>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>>> >>>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>>> So we have 4 cases to look at. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>>> >>>>>>>> What are the bean classes of those additional beans? >>>>>>>> >>>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>>> >>>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>>> >>>>>>>>> We have an >>>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>>> in a shared ear lib jar and a second one >>>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>>> in WEB-INF/classes of war1. >>>>>>>>> >>>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>>> >>>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>>> >>>>>>>>> Questions: >>>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>>> >>>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>>> >>>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>>> >>>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>>> Interesting write up! >>>>>>>>>>>> >>>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>>> >>>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, >>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>>> >>>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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. >>>> >>> >>> >>> _______________________________________________ >>> 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 struberg at yahoo.de Fri Feb 20 02:13:03 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 20 Feb 2015 08:13:03 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: <9E50A1C0-521A-48A4-BBFF-8DC932CDA69F@yahoo.de> I?ve now extracted my sample to as smallish as possible. You can find it on my github repo: https://github.com/struberg/cdi-ear-test As already explained Wildfly does badly blow up if you use Extensions: 07:59:44,121 INFO [at.struct.cdieartest.util.BaseLoggingExtension] (MSC service thread 1-4) processAnnotatedType Extension Instance: at.struct.cdieartest.war1.War1Extension at 2b8e6a22 ThreadContextClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear:main" from Service Module Loader Object ClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear.war2.war:main" from Service Module Loader params = [at.struct.cdieartest.war2.War2SampleBean] Explanation: a bean from war2 (War2SampleBean) gets posted to the Extension from war1 (War1Extension). I did not add more code to keep the sample really clean. But I guess you agree that this will cause ClassNotFound, cannot cast, etc down the road. Oh, and I don?t think other containers do much better. I know that TomEE-1.7.2-SNAPSHOT and 2.0.0-SNAPSHOT do work, but it?s very strict isolation might possibly cause other implications down the road (although much easier to handle ones). Can anybody test how GlassFish-3.1 and 4.0 (RI) behaves? Not that I care much about how the RI behaves in this unspecified case - but still good to know ;) LieGrue, strub > Am 19.02.2015 um 22:28 schrieb Romain Manni-Bucau : > > yep what's I meant by logical (technically we an do all we want) > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 21:10 GMT+01:00 Mark Struberg : >> +1 >> It?s not only logical, it?s really technically crucial. >> >> Say in war1 you call >> >> beanManager.fire(new ClassWhichOnlyExistsInWar1()); >> >> and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. >> That?s broken, broken, broken. >> >> LieGrue, >> strub From jharting at redhat.com Fri Feb 20 03:22:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 20 Feb 2015 09:22:47 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: <54E6EED7.3060402@redhat.com> On 02/19/2015 08:54 PM, Mark Struberg wrote: >> if you fire(new Object()) in war1, nothing prevents >> it from being delivered also in war2 / ejb jars > That must not happen. We can try to revisit those rules for CDI 2.0 > > Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. > > > Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. Wrong Mark, this is not how Java classloading works. You get "NoClassDefFound or ClassNotFound exceptions" if a classloader fails to load or link a class. What probably confused you in your scenario is that class A from war1 is loaded by war1 classloader and then passed to an extension loaded by war2 classloader. That however does not impact how class A is loaded / linked at all. war1 classloader will still be used to load/link it. > > I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. > > LieGrue, > strub > > > >> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >> >> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>> >>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>> >>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>> >>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>> >>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>> >>>> A - in a shared jar >>>> B - in a war >>>> >>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>> >>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>> >>>> So far we'll hopefully on the same page. >>>> >>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>> >>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>> >>>> ABean - is injectable into beans anywhere in the entire EAR >>>> BBean - is not injectable outside of the given war >>>> >>>> HTH, >>>> >>>> Jozef >>>> >>>> >>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>> >>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>> So we have 4 cases to look at. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>> >>>>>> What are the bean classes of those additional beans? >>>>>> >>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>> Again, just trying to understand how it works in Weld. >>>>>>> >>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>> >>>>>>> We have an >>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>> in a shared ear lib jar and a second one >>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>> in WEB-INF/classes of war1. >>>>>>> >>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>> >>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>> >>>>>>> Questions: >>>>>>> Q1: Which BeanManager do I get here? >>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>> >>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>> >>>>>>>> >>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>> >>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>> >>>>>>>>> >>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>> >>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>> Interesting write up! >>>>>>>>>> >>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>> >>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>> and ears from our perspective here: >>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Arjan Tijms >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>> >>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 jharting at redhat.com Fri Feb 20 03:23:25 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 20 Feb 2015 09:23:25 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> Message-ID: <54E6EEFD.7010404@redhat.com> On 02/19/2015 09:10 PM, Mark Struberg wrote: > +1 > It?s not only logical, it?s really technically crucial. > > Say in war1 you call > > beanManager.fire(new ClassWhichOnlyExistsInWar1()); > > and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. > That?s broken, broken, broken. How does it break an application? > > LieGrue, > strub > > >> Am 19.02.2015 um 20:56 schrieb Romain Manni-Bucau : >> >> Agree, the most logical + understandable (=usable) rule is to be >> aligned to classloading/structure. Breaking this simple rule >> completely breaks the common usage >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 20:54 GMT+01:00 Mark Struberg : >>>> if you fire(new Object()) in war1, nothing prevents >>>> it from being delivered also in war2 / ejb jars >>> That must not happen. >>> >>> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >>> >>> >>> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. >>> >>> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>>> >>>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>>> >>>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>>> >>>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>>> >>>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>>> >>>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>>> >>>>>> A - in a shared jar >>>>>> B - in a war >>>>>> >>>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>>> >>>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>>> >>>>>> So far we'll hopefully on the same page. >>>>>> >>>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>>> >>>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>>> >>>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>>> BBean - is not injectable outside of the given war >>>>>> >>>>>> HTH, >>>>>> >>>>>> Jozef >>>>>> >>>>>> >>>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>>> >>>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>>> So we have 4 cases to look at. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>>> >>>>>>>> What are the bean classes of those additional beans? >>>>>>>> >>>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>>> >>>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>>> >>>>>>>>> We have an >>>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>>> in a shared ear lib jar and a second one >>>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>>> in WEB-INF/classes of war1. >>>>>>>>> >>>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>>> >>>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>>> >>>>>>>>> Questions: >>>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>>> >>>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>>> >>>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>>> >>>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>>> Interesting write up! >>>>>>>>>>>> >>>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>>> >>>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, >>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>>> >>>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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. >>> >>> _______________________________________________ >>> 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 jharting at redhat.com Fri Feb 20 03:28:09 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 20 Feb 2015 09:28:09 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <9E50A1C0-521A-48A4-BBFF-8DC932CDA69F@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> <9E50A1C0-521A-48A4-BBFF-8DC932CDA69F@yahoo.de> Message-ID: <54E6F019.60902@redhat.com> On 02/20/2015 08:13 AM, Mark Struberg wrote: > I?ve now extracted my sample to as smallish as possible. > > You can find it on my github repo: > > https://github.com/struberg/cdi-ear-test > > > As already explained Wildfly does badly blow up if you use Extensions: > > 07:59:44,121 INFO [at.struct.cdieartest.util.BaseLoggingExtension] (MSC service thread 1-4) processAnnotatedType > Extension Instance: at.struct.cdieartest.war1.War1Extension at 2b8e6a22 > ThreadContextClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear:main" from Service Module Loader > Object ClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear.war2.war:main" from Service Module Loader > params = [at.struct.cdieartest.war2.War2SampleBean] Which part is the "bad blow up"? > > Explanation: a bean from war2 (War2SampleBean) gets posted to the Extension from war1 (War1Extension). > > I did not add more code to keep the sample really clean. But I guess you agree that this will cause ClassNotFound, cannot cast, etc down the road. No, this will not cause ClassNotFound nor LinkageError as explained in my previous reply. I agree with you that we should revisit observer resolution rules but let's make sure we back that up by arguments that are valid. > > Oh, and I don?t think other containers do much better. > I know that TomEE-1.7.2-SNAPSHOT and 2.0.0-SNAPSHOT do work, but it?s very strict isolation might possibly cause other implications down the road (although much easier to handle ones). > Can anybody test how GlassFish-3.1 and 4.0 (RI) behaves? Not that I care much about how the RI behaves in this unspecified case - but still good to know ;) > > > LieGrue, > strub > > > >> Am 19.02.2015 um 22:28 schrieb Romain Manni-Bucau : >> >> yep what's I meant by logical (technically we an do all we want) >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 21:10 GMT+01:00 Mark Struberg : >>> +1 >>> It?s not only logical, it?s really technically crucial. >>> >>> Say in war1 you call >>> >>> beanManager.fire(new ClassWhichOnlyExistsInWar1()); >>> >>> and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. >>> That?s broken, broken, broken. >>> >>> LieGrue, >>> strub > > _______________________________________________ > 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 struberg at yahoo.de Fri Feb 20 03:53:05 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 20 Feb 2015 09:53:05 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E6EED7.3060402@redhat.com> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> <54E6EED7.3060402@redhat.com> Message-ID: In practice you don?t only have single classes. If your class references another class in the war in a method then it WILL blow up that way. LieGrue, strub > Am 20.02.2015 um 09:22 schrieb Jozef Hartinger : > > > On 02/19/2015 08:54 PM, Mark Struberg wrote: >>> if you fire(new Object()) in war1, nothing prevents >>> it from being delivered also in war2 / ejb jars >> That must not happen. > We can try to revisit those rules for CDI 2.0 >> >> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >> >> >> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. > Wrong Mark, this is not how Java classloading works. You get "NoClassDefFound or ClassNotFound exceptions" if a classloader fails to load or link a class. What probably confused you in your scenario is that class A from war1 is loaded by war1 classloader and then passed to an extension loaded by war2 classloader. That however does not impact how class A is loaded / linked at all. war1 classloader will still be used to load/link it. >> >> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >> >> LieGrue, >> strub >> >> >> >>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>> >>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>> >>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>> >>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>> >>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>> >>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>> >>>>> A - in a shared jar >>>>> B - in a war >>>>> >>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>> >>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>> >>>>> So far we'll hopefully on the same page. >>>>> >>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>> >>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>> >>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>> BBean - is not injectable outside of the given war >>>>> >>>>> HTH, >>>>> >>>>> Jozef >>>>> >>>>> >>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>> >>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>> So we have 4 cases to look at. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>> >>>>>>> What are the bean classes of those additional beans? >>>>>>> >>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>> >>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>> >>>>>>>> We have an >>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>> in a shared ear lib jar and a second one >>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>> in WEB-INF/classes of war1. >>>>>>>> >>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>> >>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>> >>>>>>>> Questions: >>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>> >>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>> >>>>>>>> >>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>> >>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>> >>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>> Interesting write up! >>>>>>>>>>> >>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>> >>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Arjan Tijms >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>> >>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 jharting at redhat.com Fri Feb 20 03:57:56 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 20 Feb 2015 09:57:56 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> <54E6EED7.3060402@redhat.com> Message-ID: <54E6F714.2000205@redhat.com> No, it won't. The class from war1 loaded by war1 classloader will continue to use the same classloader for linkage. The fact that you send that class as a parameter to a method in a different war (classloader) does not influence class linkage anyhow. On 02/20/2015 09:53 AM, Mark Struberg wrote: > In practice you don?t only have single classes. If your class references another class in the war in a method then it WILL blow up that way. > > LieGrue, > strub > > >> Am 20.02.2015 um 09:22 schrieb Jozef Hartinger : >> >> >> On 02/19/2015 08:54 PM, Mark Struberg wrote: >>>> if you fire(new Object()) in war1, nothing prevents >>>> it from being delivered also in war2 / ejb jars >>> That must not happen. >> We can try to revisit those rules for CDI 2.0 >>> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >>> >>> >>> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. >> Wrong Mark, this is not how Java classloading works. You get "NoClassDefFound or ClassNotFound exceptions" if a classloader fails to load or link a class. What probably confused you in your scenario is that class A from war1 is loaded by war1 classloader and then passed to an extension loaded by war2 classloader. That however does not impact how class A is loaded / linked at all. war1 classloader will still be used to load/link it. >>> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>>> >>>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>>> >>>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>>> >>>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>>> >>>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>>> >>>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>>> >>>>>> A - in a shared jar >>>>>> B - in a war >>>>>> >>>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>>> >>>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>>> >>>>>> So far we'll hopefully on the same page. >>>>>> >>>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>>> >>>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>>> >>>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>>> BBean - is not injectable outside of the given war >>>>>> >>>>>> HTH, >>>>>> >>>>>> Jozef >>>>>> >>>>>> >>>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>>> >>>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>>> So we have 4 cases to look at. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>>> >>>>>>>> What are the bean classes of those additional beans? >>>>>>>> >>>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>>> >>>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>>> >>>>>>>>> We have an >>>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>>> in a shared ear lib jar and a second one >>>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>>> in WEB-INF/classes of war1. >>>>>>>>> >>>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>>> >>>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>>> >>>>>>>>> Questions: >>>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>>> >>>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>>> >>>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>>> >>>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>>> Interesting write up! >>>>>>>>>>>> >>>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>>> >>>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, >>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>>> >>>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 Fri Feb 20 04:03:34 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 20 Feb 2015 10:03:34 +0100 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <54E6F714.2000205@redhat.com> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> <54E6EED7.3060402@redhat.com> <54E6F714.2000205@redhat.com> Message-ID: @Jozef: can't work and you get far more than classnotfound, noclassdeffound and linkageerror. Or if you support it then isolation is fully broken and that's afr worse from an app behavior point of view. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-20 9:57 GMT+01:00 Jozef Hartinger : > No, it won't. The class from war1 loaded by war1 classloader will > continue to use the same classloader for linkage. The fact that you send > that class as a parameter to a method in a different war (classloader) > does not influence class linkage anyhow. > > On 02/20/2015 09:53 AM, Mark Struberg wrote: >> In practice you don?t only have single classes. If your class references another class in the war in a method then it WILL blow up that way. >> >> LieGrue, >> strub >> >> >>> Am 20.02.2015 um 09:22 schrieb Jozef Hartinger : >>> >>> >>> On 02/19/2015 08:54 PM, Mark Struberg wrote: >>>>> if you fire(new Object()) in war1, nothing prevents >>>>> it from being delivered also in war2 / ejb jars >>>> That must not happen. >>> We can try to revisit those rules for CDI 2.0 >>>> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2. >>>> >>>> >>>> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn?t work. >>> Wrong Mark, this is not how Java classloading works. You get "NoClassDefFound or ClassNotFound exceptions" if a classloader fails to load or link a class. What probably confused you in your scenario is that class A from war1 is loaded by war1 classloader and then passed to an extension loaded by war2 classloader. That however does not impact how class A is loaded / linked at all. war1 classloader will still be used to load/link it. >>>> I?ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger : >>>>> >>>>> On 02/19/2015 03:21 PM, Mark Struberg wrote: >>>>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR. >>>>>> >>>>>> And as expected it is pretty much non-portable (to avoid the word ?broken?). >>>>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ?module? handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim. >>>>>> >>>>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1? >>>>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions. >>>>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees. >>>>>> >>>>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution? >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger : >>>>>>> >>>>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes: >>>>>>> >>>>>>> A - in a shared jar >>>>>>> B - in a war >>>>>>> >>>>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows: >>>>>>> >>>>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR) >>>>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries >>>>>>> >>>>>>> So far we'll hopefully on the same page. >>>>>>> >>>>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean). >>>>>>> >>>>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with: >>>>>>> >>>>>>> ABean - is injectable into beans anywhere in the entire EAR >>>>>>> BBean - is not injectable outside of the given war >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> Jozef >>>>>>> >>>>>>> >>>>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote: >>>>>>>> There are again multiple scenarios. And you have to distinguish between BeanClass and getTypes(). >>>>>>>> >>>>>>>> Both can be either in the shared ear lib jar or in any of the WARs. >>>>>>>> So we have 4 cases to look at. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 18.02.2015 um 17:39 schrieb Jozef Hartinger : >>>>>>>>> >>>>>>>>> What are the bean classes of those additional beans? >>>>>>>>> >>>>>>>>> On 02/18/2015 04:47 PM, Mark Struberg wrote: >>>>>>>>>> Again, just trying to understand how it works in Weld. >>>>>>>>>> >>>>>>>>>> Lets do the following example: MessageBundleExtension in DeltaSpike [1]. >>>>>>>>>> >>>>>>>>>> We have an >>>>>>>>>> public interface @MessageBundle MsgInEar { .. } >>>>>>>>>> in a shared ear lib jar and a second one >>>>>>>>>> public interface @MessageBundle MsgInWar { .. } >>>>>>>>>> in WEB-INF/classes of war1. >>>>>>>>>> >>>>>>>>>> In Weld there is only 1 instance of the MessageBundleExtension for the whole EAR, right? >>>>>>>>>> >>>>>>>>>> This extension first collects all the classes annotated with @MessageBundle in a Set> via @Observes ProcessAnnotatedType. >>>>>>>>>> And in @Observes AfterBeanDiscovery we create Bean for all those found classes and add all those to the BeanManager we get as parameter. >>>>>>>>>> >>>>>>>>>> Questions: >>>>>>>>>> Q1: Which BeanManager do I get here? >>>>>>>>>> Q2: And what happens if I add a Bean with a Type X in war1 and another Bean with Type X in war2 via AfterBeanDiscovery#addBean()? >>>>>>>>>> Q3: Does this create an AmbiguousResolutionException when used? >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> PS: I am well aware that all the other solutions also have some very nasty side effects? >>>>>>>>>> >>>>>>>>>> [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 18.02.2015 um 15:54 schrieb Jozef Hartinger : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02/18/2015 03:19 PM, Mark Struberg wrote: >>>>>>>>>>>> I fear the clash in bean names across different WARs is a bug which is the direct consequence of Weld only has 1 ?User BeanManager?. It seems there are multiple kind of BeanManagers in Weld. The one that Jozef already describes is the ?BDA BeanManager?. But there must be another one. >>>>>>>>>>> That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss EAP. >>>>>>>>>>>> What happens to all the AfterBeanDiscovery#addBean() beans? Where do they get stored in App servers using Weld? >>>>>>>>>>> That should be an implementation detail. What matters where the bean is visible from - i.e. if the bean class comes from a shared lib, it should be visible globally whereas if it comes from a war it should not be visible from another war. >>>>>>>>>>>> What happens to BeforeBeanDiscovery#addScope and AfterBeanDiscovery#addContext ? >>>>>>>>>>>> If I package deltaspike-jsf (which activates the a few JSF related Contexts) in one of my WARs, do I get those also for my other WARs? What if a 2nd war tries to register the same Context? I guess this is what Romain meant when he wanted to treat each WAR as (mostly) isolated unit. >>>>>>>>>>>> >>>>>>>>>>>> Arjans experience is only the tip of the iceberg. >>>>>>>>>>>> @Arjan, I would be interested if you would run your tests against TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of workarounds to get it running on Weld. But still would love to know how far (or not) portability goes. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I do fully agree with ?1 Extension instance per Application? paragraph. But the important question is what Appliation means. This is by far not clear. The EE spec for example talks about ?multiple Applications in an EAR? in some paragraphs (meaning Web-Apps it seems). So both interpretations are ok by the strict spec wording. >>>>>>>>>>>> >>>>>>>>>>>> Of course, the other approaches have their downsides as well? >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 18.02.2015 um 12:02 schrieb arjan tijms : >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg wrote: >>>>>>>>>>>>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ >>>>>>>>>>>>> Interesting write up! >>>>>>>>>>>>> >>>>>>>>>>>>> Over at OmniFaces we had some major issues with this as well, and >>>>>>>>>>>>> blogged about that experience a little over a year ago. See >>>>>>>>>>>>> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html >>>>>>>>>>>>> >>>>>>>>>>>>> We also compiled an overview of what works and doesn't work with CDI >>>>>>>>>>>>> and ears from our perspective here: >>>>>>>>>>>>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI) >>>>>>>>>>>>> >>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> There was a lively discussion on twitter but 140 chars is way too restrictive to have a good flow ;) >>>>>>>>>>>>>> >>>>>>>>>>>>>> So please lets continue the arguments over here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>> strub >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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. > > _______________________________________________ > 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 otaviojava at java.net Fri Feb 20 16:23:07 2015 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Fri, 20 Feb 2015 19:23:07 -0200 Subject: [cdi-dev] Vetoed with Expression Message-ID: In CDI we have the Vetoed annotation[1] that vetoes the class, but we can't use expression to represent exclude this class. This feature would useful to many things, for example, an internationalization of payment[2] or just have a class that should not run when is in production. In Delta Spike[3], already there are this improvement. [1]http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/Vetoed.html [2] public interface Payment { void pay(); } @Vetoed(onExpression = "instance eq brazil", interpretedBy = PaymentInterpreter.class) class BrazilianPayment implements Payment { ... } @Vetoed(onExpression = "instance eq mexico", interpretedBy = PaymentInterpreter.class) class MexicanPayment implements Payment { ... } [3]https://deltaspike.apache.org/documentation/core.html#__exclude -- Ot?vio Gon?alves de Santana twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150220/0b853211/attachment-0001.html From issues at jboss.org Mon Feb 23 03:11:49 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 23 Feb 2015 03:11:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-385) ProcessObserverMethod is different btw spec and API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042687#comment-13042687 ] Tomas Remes commented on CDI-385: --------------------------------- [~antoinesabot-durand] There is old comment (" // These parameters are the wrong .." ) on javax.enterprise.inject.spi.ProcessObserverMethod which should be removed. > ProcessObserverMethod is different btw spec and API > --------------------------------------------------- > > Key: CDI-385 > URL: https://issues.jboss.org/browse/CDI-385 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.PFD > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Priority: Critical > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2.Final > > > As stated in CDI-88 the spec and API is different for ProcessObserverMethod. > In the spec there is a method > public AnnotatedParameter getAnnotatedEventParameter(); > but in the API there is > AnnotatedMethod getAnnotatedMethod(); > which imo makes much more sense anyway. > Thus we should amend the spec wording finally. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 23 03:34:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 23 Feb 2015 03:34:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-438: ----------------------------- Description: Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... The text: {quote} For a producer method with method **return type X** of a bean with **bean class T**, the container must raise an event of type ProcessProducerMethod. {quote} API: {code:java} /** * @param The return type of the producer method * @param The class of the bean declaring the producer method */ public interface ProcessProducerMethod extends ProcessBean { } {code} The same applies to {{ProcessProducerField}}. TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. was: Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... The text: {quote} For a producer method with method return type X of a bean with bean class T, the container must raise an event of type ProcessProducerMethod. {quote} API: {code:java} /** * @param The return type of the producer method * @param The class of the bean declaring the producer method */ public interface ProcessProducerMethod extends ProcessBean { } {code} The same applies to {{ProcessProducerField}}. TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}}. It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method **return type X** of a bean with **bean class T**, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 23 03:42:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 23 Feb 2015 03:42:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-438: ----------------------------- Description: Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... The text: {quote} For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. {quote} API: {code:java} /** * @param The return type of the producer method * @param The class of the bean declaring the producer method */ public interface ProcessProducerMethod extends ProcessBean { } {code} The same applies to {{ProcessProducerField}}. TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. was: Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... The text: {quote} For a producer method with method **return type X** of a bean with **bean class T**, the container must raise an event of type ProcessProducerMethod. {quote} API: {code:java} /** * @param The return type of the producer method * @param The class of the bean declaring the producer method */ public interface ProcessProducerMethod extends ProcessBean { } {code} The same applies to {{ProcessProducerField}}. TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Feb 23 03:46:48 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 23 Feb 2015 03:46:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042703#comment-13042703 ] Tomas Remes commented on CDI-438: --------------------------------- [[~antoinesabot-durand] This should definitely have "Fix version" 2.0 and please don't forget to remove the comments (as in CDI-385) on these classes as well. > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod. > {quote} > API: > {code:java} > /** > * @param The return type of the producer method > * @param The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod extends ProcessBean { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod}} event is not delivered to an observer with the event parameter {{ProcessBean}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From mkouba at redhat.com Tue Feb 24 09:38:38 2015 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 24 Feb 2015 15:38:38 +0100 Subject: [cdi-dev] Vetoed with Expression In-Reply-To: References: Message-ID: <54EC8CEE.808@redhat.com> Hi Ot?vio, I'm not sure if it makes sense without the notion of ProjectStage and config properties. We could probably extend @Vetoed with something similar to exclude filters [1]. Just out of curiosity - how would PaymentInterpreter evaluate "instance eq mexico"? I mean what is 'instance' resolved to and how? Martin [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#exclude_filters Dne 20.2.2015 v 22:23 Ot?vio Gon?alves de Santana napsal(a): > In CDI we have the Vetoed annotation[1] that vetoes the class, but we > can't use expression to represent exclude this class. This feature > would useful to many things, for example, an internationalization of > payment[2] or just have a class that should not run when is in > production. In Delta Spike[3], already there are this improvement. > > > [1]http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/Vetoed.html > [2] > > public interface Payment { > void pay(); > } > > @Vetoed(onExpression = "instance eq brazil", interpretedBy = > PaymentInterpreter.class) > class BrazilianPayment implements Payment { > ... > } > > @Vetoed(onExpression = "instance eq mexico", interpretedBy = > PaymentInterpreter.class) > class MexicanPayment implements Payment { > ... > } > [3]https://deltaspike.apache.org/documentation/core.html#__exclude > > -- > > Ot?vio Gon?alves de Santana > > twitter: http://twitter.com/otaviojava > site: _http://about.me/otaviojava_ > 55 (11) 98255-3513 > > > _______________________________________________ > 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 From struberg at yahoo.de Tue Feb 24 07:51:10 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 24 Feb 2015 13:51:10 +0100 Subject: [cdi-dev] CDI-2.0 feature request - interceptors on producer methods and Producer Message-ID: Hi! That?s something I came across pretty often already. We should add some way to allow producer methods to define interceptors. The same problem also happens if you write your own Beans. There is currently no way to re-use interceptors for them. LieGrue, strub From antoine at sabot-durand.net Wed Feb 25 05:30:47 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 25 Feb 2015 11:30:47 +0100 Subject: [cdi-dev] Today's meeting agenda Message-ID: <89B9CE81-FE45-4FF1-98C0-213CE691F97E@sabot-durand.net> Hi all For today's meeting I'd like to close the async events chapter by deciding if we need to explicitly activate async on observers and decide if we support context or not in async operations. Validation of java de bootstrap Api would be nice as well. Antoine Sabot-Durand From j.j.snyder at oracle.com Wed Feb 25 11:37:25 2015 From: j.j.snyder at oracle.com (JJ Snyder) Date: Wed, 25 Feb 2015 11:37:25 -0500 Subject: [cdi-dev] Extension handling in EARs In-Reply-To: <9E50A1C0-521A-48A4-BBFF-8DC932CDA69F@yahoo.de> References: <54E4A798.3010603@redhat.com> <28E51A86-C4A1-4CD0-B11E-9C0A1B408AAC@yahoo.de> <54E4C03A.5070208@redhat.com> <54E5A34D.1070003@redhat.com> <1C7C0FC1-F38F-43CA-88D4-9A296958B4BB@yahoo.de> <54E606F5.2030207@redhat.com> <65CA6201-D0AD-4558-94FB-A668B11F73FF@yahoo.de> <9E50A1C0-521A-48A4-BBFF-8DC932CDA69F@yahoo.de> Message-ID: <54EDFA45.3030803@oracle.com> Similar results for WLS and GlassFish Wls results for at.struct.cdieartest.war2.War2SampleBean #### <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <5796eac4-91c4-433f-a5aa-91c4df74cb42-00000013> <1424881286166> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > #### <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <5796eac4-91c4-433f-a5aa-91c4df74cb42-00000013> <1424881286167> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > #### <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <5796eac4-91c4-433f-a5aa-91c4df74cb42-00000013> <1424881286168> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > I?ve now extracted my sample to as smallish as possible. > > You can find it on my github repo: > > https://github.com/struberg/cdi-ear-test > > > As already explained Wildfly does badly blow up if you use Extensions: > > 07:59:44,121 INFO [at.struct.cdieartest.util.BaseLoggingExtension] (MSC service thread 1-4) processAnnotatedType > Extension Instance: at.struct.cdieartest.war1.War1Extension at 2b8e6a22 > ThreadContextClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear:main" from Service Module Loader > Object ClassLoader = ModuleClassLoader for Module "deployment.ear-1.0-SNAPSHOT.ear.war2.war:main" from Service Module Loader > params = [at.struct.cdieartest.war2.War2SampleBean] > > Explanation: a bean from war2 (War2SampleBean) gets posted to the Extension from war1 (War1Extension). > > I did not add more code to keep the sample really clean. But I guess you agree that this will cause ClassNotFound, cannot cast, etc down the road. > > Oh, and I don?t think other containers do much better. > I know that TomEE-1.7.2-SNAPSHOT and 2.0.0-SNAPSHOT do work, but it?s very strict isolation might possibly cause other implications down the road (although much easier to handle ones). > Can anybody test how GlassFish-3.1 and 4.0 (RI) behaves? Not that I care much about how the RI behaves in this unspecified case - but still good to know ;) > > > LieGrue, > strub > > > >> Am 19.02.2015 um 22:28 schrieb Romain Manni-Bucau : >> >> yep what's I meant by logical (technically we an do all we want) >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 21:10 GMT+01:00 Mark Struberg : >>> +1 >>> It?s not only logical, it?s really technically crucial. >>> >>> Say in war1 you call >>> >>> beanManager.fire(new ClassWhichOnlyExistsInWar1()); >>> >>> and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application. >>> That?s broken, broken, broken. >>> >>> LieGrue, >>> strub > > _______________________________________________ > 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 john.d.ament at gmail.com Wed Feb 25 11:53:46 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 25 Feb 2015 16:53:46 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> Message-ID: Sorry Jozef, your email fell into the pits of google inbox's "smart sorting" features. On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger wrote: > Hi John, comments inline: > > > On 02/11/2015 06:02 PM, John D. Ament wrote: > > Jozef, > > Most of what you see there is taken from the original doc, since > everyone seemed to be in agreement. I think the map is just a safeguard in > case of additional boot options available in some implementations (e.g. I > think OWB/OpenEJB have some options.. currently OpenEJB supports an > embedded CDI boot mode). > > No, I am fine with the map. What I am questioning is the type of the map. > Usually, data structures with a similar purpose use Strings as their keys. > This applies to ServletContext attributes, InvocationContext data, Servlet > request/session attributes and others. I am therefore wondering whether > there is a usecase for the proposed unbound key signature or not. > I think that's more of a placeholder, I was assuming it would be Map once we clarify everything. > > > We spoke a few times about BeanManager vs CDI. BeanManager was > preferable since there's no easy way to get the the instance, CDI is easier > to get and more aligned with how you would get it. Usually people expect > the BeanManager to be injected or available via JNDI, neither would be the > case here. > > If CDI 2.0 targets Java SE then this container initialization API will > become something that ordinary application developers use to start/stop CDI > in their applications. It therefore cannot be considered an SPI but instead > should be something easy to use. On the other hand, BeanManager is > definitely an SPI. It is used in extension, frameworks and generally for > integration. Not much by applications directly. Therefore, I don't see how > the container bootstrap API and BeanManager fit together. IMO the bootstrap > API should expose something that makes common tasks (obtaining a contextual > reference and firing and event) easy, which the CDI class does. > > Plus do not forget that BeanManager can be obtained easily using > CDI.getBeanManager(). > I'm not disagreeing. There's a few things I'd consider: - Is this mostly for new apps or existing? If existing, it's probably using some internal API, if new it can use whatever API we give. - I don't want to return void, we should give some kind of reference into the container when we're done booting. - CDI is a one step retrievable reference, where as BeanManager is a two step reference. With that said, BeanManager makes more sense to return here. Another thought could be we invent some new class that has both, but that's really redundant. > > > Yes, this is the container start API. Sounds like you have some good > ideas for things like XML configuration or programmatic configuration, both > of which are being tracked under separate tickets. One idea might be for > an optional param in the map to control packages to scan/ignore, in that > map. > > I am wondering whether this configuration should be something optional > built on top of the bootstrap API or whether we should consider making it > mandatory. Either way, we cannot add the bootstrap API to the spec without > explicitly defining how it behaves. My implicit assumption of the proposal > is that the container is supposed to scan the entire classpath for explicit > or implicit bean archives (including e.g. rt.jar), discover beans, fire > extensions, etc. This worries me as this default behavior is far from being > lightweight, which CDI for Java SE initially aimed to be. > Yes, the spec must be updated to reflect the behavior of SE mode. I plan to get that completely into the google doc before opening any spec changes in a PR. > > > We didn't want to over load the CDI interface. It already does a lot. > This is really SPI code, CDI even though it's in the spi package is used in > a lot of application code. > > I would personally prefer to have it all in one place. Having > CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more > difficult to know when to use what. > The problem is that most CDI (the interface) operations are against a running container. I think we spoke about leveraging CDIProvider at one point (in fact, I mistakenly called CDIContainer CDIProvider not even realizing it was there). I doubt that most app developers use it currently, there's not even a way to get a reference to it that I'm aware of. It's used by the implementor only. I expect that my changes in the CDI spec around this will state, along the lines of: To retrieve a CDIContainer to launch, do this: CDIContainer container = CDIContainerLocator.getCDIContainer(); container.initialize(); ... do work Once you want to shutdown the container, do this: container.shutdown(); (we may want to consider implementing AutoCloseable, an oversight on my part) and then later on - What happens if I call CDIContainerLocator in an app server - It throws an IllegalStateException. - The container provides no beans of type CDIContainer, it is managed outside of the CDI container. > > > John > > On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > wrote: > >> Hi John, some thoughts: >> >> - instead of using BeanManager it makes more sense to me to return a CDI >> instance, which is a more user-friendly API (and it also exposes access to >> BeanManager) >> - is there a usecase for arbitrary keys of the "params" map or is >> Map sufficient? >> - if we could move the shutdown() method from CDIContainer to the actual >> container handle that we obtain from initialize(), that would look more >> object-oriented >> - what exactly is initialize() supposed to do? Is it supposed to start >> scanning the entire classpath for CDI beans? That could be a problem >> especially with spring-boot-like fat jars. I think we need an API to tell >> the container which classes / packages to consider. Something like Guice's >> binding API perhaps? >> >> - the proposal makes me wonder whether retrofitting this functionality to >> the CDI class wouldn't be a better option. It could look like: >> >> CDI container = CDI.initialize(); >> container.select(Foo.class).get(); >> container.shutdown(); >> >> compare it to: >> >> CDIContainer container = CDIContainerLoader. getCDIContainer(); >> BeanManager manager = container.initialize(); >> manager.getBeans(...); >> container.shutdown(manager); >> >> >> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >> All, >> >> I have the updated API here, and wanted to solicit any final feedback >> before updating the google doc and spec pages. >> >> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >> Let me know your thoughts. >> >> Thanks, >> >> John >> >> >> _______________________________________________ >> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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/20150225/2485b906/attachment.html From jharting at redhat.com Thu Feb 26 02:32:48 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 26 Feb 2015 08:32:48 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> Message-ID: <54EECC20.6040600@redhat.com> Comments inline On 02/25/2015 05:53 PM, John D. Ament wrote: > Sorry Jozef, your email fell into the pits of google inbox's "smart > sorting" features. > > On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > wrote: > > Hi John, comments inline: > > > On 02/11/2015 06:02 PM, John D. Ament wrote: >> Jozef, >> >> Most of what you see there is taken from the original doc, since >> everyone seemed to be in agreement. I think the map is just a >> safeguard in case of additional boot options available in some >> implementations (e.g. I think OWB/OpenEJB have some options.. >> currently OpenEJB supports an embedded CDI boot mode). > No, I am fine with the map. What I am questioning is the type of > the map. Usually, data structures with a similar purpose use > Strings as their keys. This applies to ServletContext attributes, > InvocationContext data, Servlet request/session attributes and > others. I am therefore wondering whether there is a usecase for > the proposed unbound key signature or not. > > > I think that's more of a placeholder, I was assuming it would be > Map once we clarify everything. > > >> >> We spoke a few times about BeanManager vs CDI. BeanManager was >> preferable since there's no easy way to get the the instance, CDI >> is easier to get and more aligned with how you would get it. >> Usually people expect the BeanManager to be injected or available >> via JNDI, neither would be the case here. > If CDI 2.0 targets Java SE then this container initialization API > will become something that ordinary application developers use to > start/stop CDI in their applications. It therefore cannot be > considered an SPI but instead should be something easy to use. On > the other hand, BeanManager is definitely an SPI. It is used in > extension, frameworks and generally for integration. Not much by > applications directly. Therefore, I don't see how the container > bootstrap API and BeanManager fit together. IMO the bootstrap API > should expose something that makes common tasks (obtaining a > contextual reference and firing and event) easy, which the CDI > class does. > > Plus do not forget that BeanManager can be obtained easily using > CDI.getBeanManager(). > > > I'm not disagreeing. There's a few things I'd consider: > > - Is this mostly for new apps or existing? If existing, it's probably > using some internal API, if new it can use whatever API we give. > - I don't want to return void, we should give some kind of reference > into the container when we're done booting. Agreed, we should not be returning void. > - CDI is a one step retrievable reference, where as BeanManager is a > two step reference. With that said, BeanManager makes more sense to > return here. Another thought could be we invent some new class that > has both, but that's really redundant. Why do you think BeanManager makes more sense here? Especially given the assumption that application code is going to call this init/shutdown API, I don't see BeanManager as making more sense. > > >> >> Yes, this is the container start API. Sounds like you have some >> good ideas for things like XML configuration or programmatic >> configuration, both of which are being tracked under separate >> tickets. One idea might be for an optional param in the map to >> control packages to scan/ignore, in that map. > I am wondering whether this configuration should be something > optional built on top of the bootstrap API or whether we should > consider making it mandatory. Either way, we cannot add the > bootstrap API to the spec without explicitly defining how it > behaves. My implicit assumption of the proposal is that the > container is supposed to scan the entire classpath for explicit or > implicit bean archives (including e.g. rt.jar), discover beans, > fire extensions, etc. This worries me as this default behavior is > far from being lightweight, which CDI for Java SE initially aimed > to be. > > > Yes, the spec must be updated to reflect the behavior of SE mode. I > plan to get that completely into the google doc before opening any > spec changes in a PR. > > >> >> We didn't want to over load the CDI interface. It already does a >> lot. This is really SPI code, CDI even though it's in the spi >> package is used in a lot of application code. > I would personally prefer to have it all in one place. Having > CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it > more difficult to know when to use what. > > > The problem is that most CDI (the interface) operations are against a > running container. I think we spoke about leveraging CDIProvider at > one point (in fact, I mistakenly called CDIContainer CDIProvider not > even realizing it was there). I doubt that most app developers use it > currently, there's not even a way to get a reference to it that I'm > aware of. It's used by the implementor only. I don't think there's a conflict. CDI class would still only provide methods to be run against a running container. The difference is that there would be additional static methods to get this running container (CDI class) to you by starting the container. Either way, I agree that reusing CDIProvider is a must. There is no reason to define a new class for the same purpose. > > I expect that my changes in the CDI spec around this will state, along > the lines of: > > To retrieve a CDIContainer to launch, do this: > > CDIContainer container = CDIContainerLocator.getCDIContainer(); > container.initialize(); > ... do work > > Once you want to shutdown the container, do this: > > container.shutdown(); > > (we may want to consider implementing AutoCloseable, an oversight on > my part) > > and then later on > > - What happens if I call CDIContainerLocator in an app server > > - It throws an IllegalStateException. > > - The container provides no beans of type CDIContainer, it is managed > outside of the CDI container. > > >> >> John >> >> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >> > wrote: >> >> Hi John, some thoughts: >> >> - instead of using BeanManager it makes more sense to me to >> return a CDI instance, which is a more user-friendly API (and >> it also exposes access to BeanManager) >> - is there a usecase for arbitrary keys of the "params" map >> or is Map sufficient? >> - if we could move the shutdown() method from CDIContainer to >> the actual container handle that we obtain from initialize(), >> that would look more object-oriented >> - what exactly is initialize() supposed to do? Is it supposed >> to start scanning the entire classpath for CDI beans? That >> could be a problem especially with spring-boot-like fat jars. >> I think we need an API to tell the container which classes / >> packages to consider. Something like Guice's binding API perhaps? >> >> - the proposal makes me wonder whether retrofitting this >> functionality to the CDI class wouldn't be a better option. >> It could look like: >> >> CDI container = CDI.initialize(); >> container.select(Foo.class).get(); >> container.shutdown(); >> >> compare it to: >> >> CDIContainer container = CDIContainerLoader. getCDIContainer(); >> BeanManager manager = container.initialize(); >> manager.getBeans(...); >> container.shutdown(manager); >> >> >> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> All, >>> >>> I have the updated API here, and wanted to solicit any final >>> feedback before updating the google doc and spec pages. >>> >>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>> Let me know your thoughts. >>> >>> Thanks, >>> >>> John >>> >>> >>> _______________________________________________ >>> 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/20150226/bd600171/attachment-0001.html From rmannibucau at gmail.com Thu Feb 26 02:58:33 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 26 Feb 2015 08:58:33 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54EECC20.6040600@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> Message-ID: Hi guys why note keeping it simple? try (CDIContainer container = CDIContainer.newCDIContainer(/* optional map to configure vendor features */)) { CDI.current().getBeanManager().... } Not sure the point having initialize() + having shutdown = close really makes the API more fluent and modern IMO. Also to be fully SE I guess provider() method would be needed even if optional (SPI usage by default): try (CDIContainer container = CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) { CDI.current().getBeanManager().... } Finally I think having a kind of getInstance shortcut could be a plus for SE: try (CDIContainer container = CDIContainer.newCDIContainer()) { container.newInstance(MyAppRunner.class /* optional qualifiers */ ).run(args); } Using container to get an instance would create the instance and bind it to the container lifecycle (mainly for predestroy) avoiding this boilerplate code in all main which will surely only be used to launch a soft. wdyt? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : > Comments inline > > On 02/25/2015 05:53 PM, John D. Ament wrote: > > Sorry Jozef, your email fell into the pits of google inbox's "smart sorting" > features. > > On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger wrote: >> >> Hi John, comments inline: >> >> >> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >> Jozef, >> >> Most of what you see there is taken from the original doc, since everyone >> seemed to be in agreement. I think the map is just a safeguard in case of >> additional boot options available in some implementations (e.g. I think >> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded CDI >> boot mode). >> >> No, I am fine with the map. What I am questioning is the type of the map. >> Usually, data structures with a similar purpose use Strings as their keys. >> This applies to ServletContext attributes, InvocationContext data, Servlet >> request/session attributes and others. I am therefore wondering whether >> there is a usecase for the proposed unbound key signature or not. > > > I think that's more of a placeholder, I was assuming it would be > Map once we clarify everything. > >> >> >> >> We spoke a few times about BeanManager vs CDI. BeanManager was preferable >> since there's no easy way to get the the instance, CDI is easier to get and >> more aligned with how you would get it. Usually people expect the >> BeanManager to be injected or available via JNDI, neither would be the case >> here. >> >> If CDI 2.0 targets Java SE then this container initialization API will >> become something that ordinary application developers use to start/stop CDI >> in their applications. It therefore cannot be considered an SPI but instead >> should be something easy to use. On the other hand, BeanManager is >> definitely an SPI. It is used in extension, frameworks and generally for >> integration. Not much by applications directly. Therefore, I don't see how >> the container bootstrap API and BeanManager fit together. IMO the bootstrap >> API should expose something that makes common tasks (obtaining a contextual >> reference and firing and event) easy, which the CDI class does. >> >> Plus do not forget that BeanManager can be obtained easily using >> CDI.getBeanManager(). > > > I'm not disagreeing. There's a few things I'd consider: > > - Is this mostly for new apps or existing? If existing, it's probably using > some internal API, if new it can use whatever API we give. > - I don't want to return void, we should give some kind of reference into > the container when we're done booting. > > Agreed, we should not be returning void. > > - CDI is a one step retrievable reference, where as BeanManager is a two > step reference. With that said, BeanManager makes more sense to return > here. Another thought could be we invent some new class that has both, but > that's really redundant. > > Why do you think BeanManager makes more sense here? Especially given the > assumption that application code is going to call this init/shutdown API, I > don't see BeanManager as making more sense. > > >> >> >> >> Yes, this is the container start API. Sounds like you have some good >> ideas for things like XML configuration or programmatic configuration, both >> of which are being tracked under separate tickets. One idea might be for an >> optional param in the map to control packages to scan/ignore, in that map. >> >> I am wondering whether this configuration should be something optional >> built on top of the bootstrap API or whether we should consider making it >> mandatory. Either way, we cannot add the bootstrap API to the spec without >> explicitly defining how it behaves. My implicit assumption of the proposal >> is that the container is supposed to scan the entire classpath for explicit >> or implicit bean archives (including e.g. rt.jar), discover beans, fire >> extensions, etc. This worries me as this default behavior is far from being >> lightweight, which CDI for Java SE initially aimed to be. > > > Yes, the spec must be updated to reflect the behavior of SE mode. I plan to > get that completely into the google doc before opening any spec changes in a > PR. > >> >> >> >> We didn't want to over load the CDI interface. It already does a lot. >> This is really SPI code, CDI even though it's in the spi package is used in >> a lot of application code. >> >> I would personally prefer to have it all in one place. Having >> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >> difficult to know when to use what. > > > The problem is that most CDI (the interface) operations are against a > running container. I think we spoke about leveraging CDIProvider at one > point (in fact, I mistakenly called CDIContainer CDIProvider not even > realizing it was there). I doubt that most app developers use it currently, > there's not even a way to get a reference to it that I'm aware of. It's > used by the implementor only. > > I don't think there's a conflict. CDI class would still only provide methods > to be run against a running container. The difference is that there would be > additional static methods to get this running container (CDI class) to you > by starting the container. > > Either way, I agree that reusing CDIProvider is a must. There is no reason > to define a new class for the same purpose. > > > I expect that my changes in the CDI spec around this will state, along the > lines of: > > To retrieve a CDIContainer to launch, do this: > > CDIContainer container = CDIContainerLocator.getCDIContainer(); > container.initialize(); > ... do work > > Once you want to shutdown the container, do this: > > container.shutdown(); > > (we may want to consider implementing AutoCloseable, an oversight on my > part) > > and then later on > > - What happens if I call CDIContainerLocator in an app server > > - It throws an IllegalStateException. > > - The container provides no beans of type CDIContainer, it is managed > outside of the CDI container. > > >> >> >> >> John >> >> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >> wrote: >>> >>> Hi John, some thoughts: >>> >>> - instead of using BeanManager it makes more sense to me to return a CDI >>> instance, which is a more user-friendly API (and it also exposes access to >>> BeanManager) >>> - is there a usecase for arbitrary keys of the "params" map or is >>> Map sufficient? >>> - if we could move the shutdown() method from CDIContainer to the actual >>> container handle that we obtain from initialize(), that would look more >>> object-oriented >>> - what exactly is initialize() supposed to do? Is it supposed to start >>> scanning the entire classpath for CDI beans? That could be a problem >>> especially with spring-boot-like fat jars. I think we need an API to tell >>> the container which classes / packages to consider. Something like Guice's >>> binding API perhaps? >>> >>> - the proposal makes me wonder whether retrofitting this functionality to >>> the CDI class wouldn't be a better option. It could look like: >>> >>> CDI container = CDI.initialize(); >>> container.select(Foo.class).get(); >>> container.shutdown(); >>> >>> compare it to: >>> >>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>> BeanManager manager = container.initialize(); >>> manager.getBeans(...); >>> container.shutdown(manager); >>> >>> >>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>> All, >>> >>> I have the updated API here, and wanted to solicit any final feedback >>> before updating the google doc and spec pages. >>> >>> >>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>> Let me know your thoughts. >>> >>> Thanks, >>> >>> John >>> >>> >>> _______________________________________________ >>> 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 jharting at redhat.com Thu Feb 26 10:19:10 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 26 Feb 2015 16:19:10 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> Message-ID: <54EF396E.20805@redhat.com> I like the initialize + close() combination and the try-with-resources usage. What looks weird to me is that at line one you obtain a container handle: try (CDIContainer container = CDIContainer.newCDIContai... CDI.current().getBeanManager() ... and then at line two you call a static method to perform a container lookup :-/ An API that allows you to use the container handle you already got is way better IMO, e.g.: try (CDIContainer container = CDIContainer.newCDIContai... container.getBeanManager() If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, we get this easily. On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > Hi guys > > why note keeping it simple? > > try (CDIContainer container = CDIContainer.newCDIContainer(/* optional > map to configure vendor features */)) { > CDI.current().getBeanManager().... > } > > Not sure the point having initialize() + having shutdown = close > really makes the API more fluent and modern IMO. > > Also to be fully SE I guess provider() method would be needed even if > optional (SPI usage by default): > > try (CDIContainer container = > CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > { > CDI.current().getBeanManager().... > } > > Finally I think having a kind of getInstance shortcut could be a plus for SE: > > try (CDIContainer container = CDIContainer.newCDIContainer()) { > container.newInstance(MyAppRunner.class /* optional qualifiers */ > ).run(args); > } > > Using container to get an instance would create the instance and bind > it to the container lifecycle (mainly for predestroy) avoiding this > boilerplate code in all main which will surely only be used to launch > a soft. > > wdyt? > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >> Comments inline >> >> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >> Sorry Jozef, your email fell into the pits of google inbox's "smart sorting" >> features. >> >> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger wrote: >>> Hi John, comments inline: >>> >>> >>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>> Jozef, >>> >>> Most of what you see there is taken from the original doc, since everyone >>> seemed to be in agreement. I think the map is just a safeguard in case of >>> additional boot options available in some implementations (e.g. I think >>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded CDI >>> boot mode). >>> >>> No, I am fine with the map. What I am questioning is the type of the map. >>> Usually, data structures with a similar purpose use Strings as their keys. >>> This applies to ServletContext attributes, InvocationContext data, Servlet >>> request/session attributes and others. I am therefore wondering whether >>> there is a usecase for the proposed unbound key signature or not. >> >> I think that's more of a placeholder, I was assuming it would be >> Map once we clarify everything. >> >>> >>> >>> We spoke a few times about BeanManager vs CDI. BeanManager was preferable >>> since there's no easy way to get the the instance, CDI is easier to get and >>> more aligned with how you would get it. Usually people expect the >>> BeanManager to be injected or available via JNDI, neither would be the case >>> here. >>> >>> If CDI 2.0 targets Java SE then this container initialization API will >>> become something that ordinary application developers use to start/stop CDI >>> in their applications. It therefore cannot be considered an SPI but instead >>> should be something easy to use. On the other hand, BeanManager is >>> definitely an SPI. It is used in extension, frameworks and generally for >>> integration. Not much by applications directly. Therefore, I don't see how >>> the container bootstrap API and BeanManager fit together. IMO the bootstrap >>> API should expose something that makes common tasks (obtaining a contextual >>> reference and firing and event) easy, which the CDI class does. >>> >>> Plus do not forget that BeanManager can be obtained easily using >>> CDI.getBeanManager(). >> >> I'm not disagreeing. There's a few things I'd consider: >> >> - Is this mostly for new apps or existing? If existing, it's probably using >> some internal API, if new it can use whatever API we give. >> - I don't want to return void, we should give some kind of reference into >> the container when we're done booting. >> >> Agreed, we should not be returning void. >> >> - CDI is a one step retrievable reference, where as BeanManager is a two >> step reference. With that said, BeanManager makes more sense to return >> here. Another thought could be we invent some new class that has both, but >> that's really redundant. >> >> Why do you think BeanManager makes more sense here? Especially given the >> assumption that application code is going to call this init/shutdown API, I >> don't see BeanManager as making more sense. >> >> >>> >>> >>> Yes, this is the container start API. Sounds like you have some good >>> ideas for things like XML configuration or programmatic configuration, both >>> of which are being tracked under separate tickets. One idea might be for an >>> optional param in the map to control packages to scan/ignore, in that map. >>> >>> I am wondering whether this configuration should be something optional >>> built on top of the bootstrap API or whether we should consider making it >>> mandatory. Either way, we cannot add the bootstrap API to the spec without >>> explicitly defining how it behaves. My implicit assumption of the proposal >>> is that the container is supposed to scan the entire classpath for explicit >>> or implicit bean archives (including e.g. rt.jar), discover beans, fire >>> extensions, etc. This worries me as this default behavior is far from being >>> lightweight, which CDI for Java SE initially aimed to be. >> >> Yes, the spec must be updated to reflect the behavior of SE mode. I plan to >> get that completely into the google doc before opening any spec changes in a >> PR. >> >>> >>> >>> We didn't want to over load the CDI interface. It already does a lot. >>> This is really SPI code, CDI even though it's in the spi package is used in >>> a lot of application code. >>> >>> I would personally prefer to have it all in one place. Having >>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>> difficult to know when to use what. >> >> The problem is that most CDI (the interface) operations are against a >> running container. I think we spoke about leveraging CDIProvider at one >> point (in fact, I mistakenly called CDIContainer CDIProvider not even >> realizing it was there). I doubt that most app developers use it currently, >> there's not even a way to get a reference to it that I'm aware of. It's >> used by the implementor only. >> >> I don't think there's a conflict. CDI class would still only provide methods >> to be run against a running container. The difference is that there would be >> additional static methods to get this running container (CDI class) to you >> by starting the container. >> >> Either way, I agree that reusing CDIProvider is a must. There is no reason >> to define a new class for the same purpose. >> >> >> I expect that my changes in the CDI spec around this will state, along the >> lines of: >> >> To retrieve a CDIContainer to launch, do this: >> >> CDIContainer container = CDIContainerLocator.getCDIContainer(); >> container.initialize(); >> ... do work >> >> Once you want to shutdown the container, do this: >> >> container.shutdown(); >> >> (we may want to consider implementing AutoCloseable, an oversight on my >> part) >> >> and then later on >> >> - What happens if I call CDIContainerLocator in an app server >> >> - It throws an IllegalStateException. >> >> - The container provides no beans of type CDIContainer, it is managed >> outside of the CDI container. >> >> >>> >>> >>> John >>> >>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >>> wrote: >>>> Hi John, some thoughts: >>>> >>>> - instead of using BeanManager it makes more sense to me to return a CDI >>>> instance, which is a more user-friendly API (and it also exposes access to >>>> BeanManager) >>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> Map sufficient? >>>> - if we could move the shutdown() method from CDIContainer to the actual >>>> container handle that we obtain from initialize(), that would look more >>>> object-oriented >>>> - what exactly is initialize() supposed to do? Is it supposed to start >>>> scanning the entire classpath for CDI beans? That could be a problem >>>> especially with spring-boot-like fat jars. I think we need an API to tell >>>> the container which classes / packages to consider. Something like Guice's >>>> binding API perhaps? >>>> >>>> - the proposal makes me wonder whether retrofitting this functionality to >>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>> CDI container = CDI.initialize(); >>>> container.select(Foo.class).get(); >>>> container.shutdown(); >>>> >>>> compare it to: >>>> >>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> BeanManager manager = container.initialize(); >>>> manager.getBeans(...); >>>> container.shutdown(manager); >>>> >>>> >>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>> All, >>>> >>>> I have the updated API here, and wanted to solicit any final feedback >>>> before updating the google doc and spec pages. >>>> >>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>> Let me know your thoughts. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Feb 26 11:42:59 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 26 Feb 2015 17:42:59 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54EF396E.20805@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> Message-ID: Not sure I get how a CDI instance can help. But container.getBeanManager() sounds nice is not a shortcut for CDI.current().getBm() otherwise it looks like duplication to me. Can we make container not contextual - dont think so? If so it makes sense otherwise I fear it doesnt add much. Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a ?crit : > I like the initialize + close() combination and the try-with-resources > usage. > What looks weird to me is that at line one you obtain a container handle: > > try (CDIContainer container = CDIContainer.newCDIContai... > CDI.current().getBeanManager() ... > > and then at line two you call a static method to perform a container > lookup :-/ > > An API that allows you to use the container handle you already got is way > better IMO, e.g.: > > try (CDIContainer container = CDIContainer.newCDIContai... > container.getBeanManager() > > If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, > we get this easily. > > On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >> Hi guys >> >> why note keeping it simple? >> >> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional >> map to configure vendor features */)) { >> CDI.current().getBeanManager().... >> } >> >> Not sure the point having initialize() + having shutdown = close >> really makes the API more fluent and modern IMO. >> >> Also to be fully SE I guess provider() method would be needed even if >> optional (SPI usage by default): >> >> try (CDIContainer container = >> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >> newCDIContainer()) >> { >> CDI.current().getBeanManager().... >> } >> >> Finally I think having a kind of getInstance shortcut could be a plus for >> SE: >> >> try (CDIContainer container = CDIContainer.newCDIContainer()) { >> container.newInstance(MyAppRunner.class /* optional qualifiers */ >> ).run(args); >> } >> >> Using container to get an instance would create the instance and bind >> it to the container lifecycle (mainly for predestroy) avoiding this >> boilerplate code in all main which will surely only be used to launch >> a soft. >> >> wdyt? >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >> >>> Comments inline >>> >>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>> sorting" >>> features. >>> >>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >>> wrote: >>> >>>> Hi John, comments inline: >>>> >>>> >>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>> Jozef, >>>> >>>> Most of what you see there is taken from the original doc, since >>>> everyone >>>> seemed to be in agreement. I think the map is just a safeguard in case >>>> of >>>> additional boot options available in some implementations (e.g. I think >>>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded >>>> CDI >>>> boot mode). >>>> >>>> No, I am fine with the map. What I am questioning is the type of the >>>> map. >>>> Usually, data structures with a similar purpose use Strings as their >>>> keys. >>>> This applies to ServletContext attributes, InvocationContext data, >>>> Servlet >>>> request/session attributes and others. I am therefore wondering whether >>>> there is a usecase for the proposed unbound key signature or not. >>>> >>> >>> I think that's more of a placeholder, I was assuming it would be >>> Map once we clarify everything. >>> >>> >>>> >>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> preferable >>>> since there's no easy way to get the the instance, CDI is easier to get >>>> and >>>> more aligned with how you would get it. Usually people expect the >>>> BeanManager to be injected or available via JNDI, neither would be the >>>> case >>>> here. >>>> >>>> If CDI 2.0 targets Java SE then this container initialization API will >>>> become something that ordinary application developers use to start/stop >>>> CDI >>>> in their applications. It therefore cannot be considered an SPI but >>>> instead >>>> should be something easy to use. On the other hand, BeanManager is >>>> definitely an SPI. It is used in extension, frameworks and generally for >>>> integration. Not much by applications directly. Therefore, I don't see >>>> how >>>> the container bootstrap API and BeanManager fit together. IMO the >>>> bootstrap >>>> API should expose something that makes common tasks (obtaining a >>>> contextual >>>> reference and firing and event) easy, which the CDI class does. >>>> >>>> Plus do not forget that BeanManager can be obtained easily using >>>> CDI.getBeanManager(). >>>> >>> >>> I'm not disagreeing. There's a few things I'd consider: >>> >>> - Is this mostly for new apps or existing? If existing, it's probably >>> using >>> some internal API, if new it can use whatever API we give. >>> - I don't want to return void, we should give some kind of reference into >>> the container when we're done booting. >>> >>> Agreed, we should not be returning void. >>> >>> - CDI is a one step retrievable reference, where as BeanManager is a two >>> step reference. With that said, BeanManager makes more sense to return >>> here. Another thought could be we invent some new class that has both, >>> but >>> that's really redundant. >>> >>> Why do you think BeanManager makes more sense here? Especially given the >>> assumption that application code is going to call this init/shutdown >>> API, I >>> don't see BeanManager as making more sense. >>> >>> >>> >>>> >>>> Yes, this is the container start API. Sounds like you have some good >>>> ideas for things like XML configuration or programmatic configuration, >>>> both >>>> of which are being tracked under separate tickets. One idea might be >>>> for an >>>> optional param in the map to control packages to scan/ignore, in that >>>> map. >>>> >>>> I am wondering whether this configuration should be something optional >>>> built on top of the bootstrap API or whether we should consider making >>>> it >>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> without >>>> explicitly defining how it behaves. My implicit assumption of the >>>> proposal >>>> is that the container is supposed to scan the entire classpath for >>>> explicit >>>> or implicit bean archives (including e.g. rt.jar), discover beans, fire >>>> extensions, etc. This worries me as this default behavior is far from >>>> being >>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>> >>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>> plan to >>> get that completely into the google doc before opening any spec changes >>> in a >>> PR. >>> >>> >>>> >>>> We didn't want to over load the CDI interface. It already does a lot. >>>> This is really SPI code, CDI even though it's in the spi package is >>>> used in >>>> a lot of application code. >>>> >>>> I would personally prefer to have it all in one place. Having >>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>>> difficult to know when to use what. >>>> >>> >>> The problem is that most CDI (the interface) operations are against a >>> running container. I think we spoke about leveraging CDIProvider at one >>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >>> realizing it was there). I doubt that most app developers use it >>> currently, >>> there's not even a way to get a reference to it that I'm aware of. It's >>> used by the implementor only. >>> >>> I don't think there's a conflict. CDI class would still only provide >>> methods >>> to be run against a running container. The difference is that there >>> would be >>> additional static methods to get this running container (CDI class) to >>> you >>> by starting the container. >>> >>> Either way, I agree that reusing CDIProvider is a must. There is no >>> reason >>> to define a new class for the same purpose. >>> >>> >>> I expect that my changes in the CDI spec around this will state, along >>> the >>> lines of: >>> >>> To retrieve a CDIContainer to launch, do this: >>> >>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>> container.initialize(); >>> ... do work >>> >>> Once you want to shutdown the container, do this: >>> >>> container.shutdown(); >>> >>> (we may want to consider implementing AutoCloseable, an oversight on my >>> part) >>> >>> and then later on >>> >>> - What happens if I call CDIContainerLocator in an app server >>> >>> - It throws an IllegalStateException. >>> >>> - The container provides no beans of type CDIContainer, it is managed >>> outside of the CDI container. >>> >>> >>> >>>> >>>> John >>>> >>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >>>> wrote: >>>> >>>>> Hi John, some thoughts: >>>>> >>>>> - instead of using BeanManager it makes more sense to me to return a >>>>> CDI >>>>> instance, which is a more user-friendly API (and it also exposes >>>>> access to >>>>> BeanManager) >>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>>> Map sufficient? >>>>> - if we could move the shutdown() method from CDIContainer to the >>>>> actual >>>>> container handle that we obtain from initialize(), that would look more >>>>> object-oriented >>>>> - what exactly is initialize() supposed to do? Is it supposed to start >>>>> scanning the entire classpath for CDI beans? That could be a problem >>>>> especially with spring-boot-like fat jars. I think we need an API to >>>>> tell >>>>> the container which classes / packages to consider. Something like >>>>> Guice's >>>>> binding API perhaps? >>>>> >>>>> - the proposal makes me wonder whether retrofitting this functionality >>>>> to >>>>> the CDI class wouldn't be a better option. It could look like: >>>>> >>>>> CDI container = CDI.initialize(); >>>>> container.select(Foo.class).get(); >>>>> container.shutdown(); >>>>> >>>>> compare it to: >>>>> >>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>> BeanManager manager = container.initialize(); >>>>> manager.getBeans(...); >>>>> container.shutdown(manager); >>>>> >>>>> >>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>> >>>>> All, >>>>> >>>>> I have the updated API here, and wanted to solicit any final feedback >>>>> before updating the google doc and spec pages. >>>>> >>>>> >>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151dda >>>>> d467a1c01c >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20150226/dc02ff7a/attachment-0001.html From jharting at redhat.com Fri Feb 27 02:05:04 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 27 Feb 2015 08:05:04 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> Message-ID: <54F01720.3080802@redhat.com> My point is that from the application perspective, the user obtains one container handle for eventual shutdown (CDIContainer) and then looks up a different container handle (CDI) that they can use for real work (lookup / event dispatch / etc.) It would be cleaner if the container gave away a single handle that can do all of that. On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > Not sure I get how a CDI instance can help. > > But container.getBeanManager() sounds nice is not a shortcut for > CDI.current().getBm() otherwise it looks like duplication to me. > > Can we make container not contextual - dont think so? If so it makes > sense otherwise I fear it doesnt add much. > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > a ?crit : > > I like the initialize + close() combination and the > try-with-resources usage. > What looks weird to me is that at line one you obtain a container > handle: > > try (CDIContainer container = CDIContainer.newCDIContai... > CDI.current().getBeanManager() ... > > and then at line two you call a static method to perform a > container lookup :-/ > > An API that allows you to use the container handle you already got > is way better IMO, e.g.: > > try (CDIContainer container = CDIContainer.newCDIContai... > container.getBeanManager() > > If CDIContainer.newCDIContainer() returns an CDI instance or its > subclass, we get this easily. > > On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > > Hi guys > > why note keeping it simple? > > try (CDIContainer container = CDIContainer.newCDIContainer(/* > optional > map to configure vendor features */)) { > CDI.current().getBeanManager().... > } > > Not sure the point having initialize() + having shutdown = close > really makes the API more fluent and modern IMO. > > Also to be fully SE I guess provider() method would be needed > even if > optional (SPI usage by default): > > try (CDIContainer container = > CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > { > CDI.current().getBeanManager().... > } > > Finally I think having a kind of getInstance shortcut could be > a plus for SE: > > try (CDIContainer container = CDIContainer.newCDIContainer()) { > container.newInstance(MyAppRunner.class /* optional > qualifiers */ > ).run(args); > } > > Using container to get an instance would create the instance > and bind > it to the container lifecycle (mainly for predestroy) avoiding > this > boilerplate code in all main which will surely only be used to > launch > a soft. > > wdyt? > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >: > > Comments inline > > On 02/25/2015 05:53 PM, John D. Ament wrote: > > Sorry Jozef, your email fell into the pits of google > inbox's "smart sorting" > features. > > On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > wrote: > > Hi John, comments inline: > > > On 02/11/2015 06:02 PM, John D. Ament wrote: > > Jozef, > > Most of what you see there is taken from the original > doc, since everyone > seemed to be in agreement. I think the map is just a > safeguard in case of > additional boot options available in some > implementations (e.g. I think > OWB/OpenEJB have some options.. currently OpenEJB > supports an embedded CDI > boot mode). > > No, I am fine with the map. What I am questioning is > the type of the map. > Usually, data structures with a similar purpose use > Strings as their keys. > This applies to ServletContext attributes, > InvocationContext data, Servlet > request/session attributes and others. I am therefore > wondering whether > there is a usecase for the proposed unbound key > signature or not. > > > I think that's more of a placeholder, I was assuming it > would be > Map once we clarify everything. > > > > We spoke a few times about BeanManager vs CDI. > BeanManager was preferable > since there's no easy way to get the the instance, CDI > is easier to get and > more aligned with how you would get it. Usually > people expect the > BeanManager to be injected or available via JNDI, > neither would be the case > here. > > If CDI 2.0 targets Java SE then this container > initialization API will > become something that ordinary application developers > use to start/stop CDI > in their applications. It therefore cannot be > considered an SPI but instead > should be something easy to use. On the other hand, > BeanManager is > definitely an SPI. It is used in extension, frameworks > and generally for > integration. Not much by applications directly. > Therefore, I don't see how > the container bootstrap API and BeanManager fit > together. IMO the bootstrap > API should expose something that makes common tasks > (obtaining a contextual > reference and firing and event) easy, which the CDI > class does. > > Plus do not forget that BeanManager can be obtained > easily using > CDI.getBeanManager(). > > > I'm not disagreeing. There's a few things I'd consider: > > - Is this mostly for new apps or existing? If existing, > it's probably using > some internal API, if new it can use whatever API we give. > - I don't want to return void, we should give some kind of > reference into > the container when we're done booting. > > Agreed, we should not be returning void. > > - CDI is a one step retrievable reference, where as > BeanManager is a two > step reference. With that said, BeanManager makes more > sense to return > here. Another thought could be we invent some new class > that has both, but > that's really redundant. > > Why do you think BeanManager makes more sense here? > Especially given the > assumption that application code is going to call this > init/shutdown API, I > don't see BeanManager as making more sense. > > > > > Yes, this is the container start API. Sounds like you > have some good > ideas for things like XML configuration or > programmatic configuration, both > of which are being tracked under separate tickets. > One idea might be for an > optional param in the map to control packages to > scan/ignore, in that map. > > I am wondering whether this configuration should be > something optional > built on top of the bootstrap API or whether we should > consider making it > mandatory. Either way, we cannot add the bootstrap API > to the spec without > explicitly defining how it behaves. My implicit > assumption of the proposal > is that the container is supposed to scan the entire > classpath for explicit > or implicit bean archives (including e.g. rt.jar), > discover beans, fire > extensions, etc. This worries me as this default > behavior is far from being > lightweight, which CDI for Java SE initially aimed to be. > > > Yes, the spec must be updated to reflect the behavior of > SE mode. I plan to > get that completely into the google doc before opening any > spec changes in a > PR. > > > > We didn't want to over load the CDI interface. It > already does a lot. > This is really SPI code, CDI even though it's in the > spi package is used in > a lot of application code. > > I would personally prefer to have it all in one place. > Having > CDIContainer, CDIContainerLoader, CDI and CDIProvider > makes it more > difficult to know when to use what. > > > The problem is that most CDI (the interface) operations > are against a > running container. I think we spoke about leveraging > CDIProvider at one > point (in fact, I mistakenly called CDIContainer > CDIProvider not even > realizing it was there). I doubt that most app developers > use it currently, > there's not even a way to get a reference to it that I'm > aware of. It's > used by the implementor only. > > I don't think there's a conflict. CDI class would still > only provide methods > to be run against a running container. The difference is > that there would be > additional static methods to get this running container > (CDI class) to you > by starting the container. > > Either way, I agree that reusing CDIProvider is a must. > There is no reason > to define a new class for the same purpose. > > > I expect that my changes in the CDI spec around this will > state, along the > lines of: > > To retrieve a CDIContainer to launch, do this: > > CDIContainer container = > CDIContainerLocator.getCDIContainer(); > container.initialize(); > ... do work > > Once you want to shutdown the container, do this: > > container.shutdown(); > > (we may want to consider implementing AutoCloseable, an > oversight on my > part) > > and then later on > > - What happens if I call CDIContainerLocator in an app server > > - It throws an IllegalStateException. > > - The container provides no beans of type CDIContainer, it > is managed > outside of the CDI container. > > > > > John > > On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > > > wrote: > > Hi John, some thoughts: > > - instead of using BeanManager it makes more sense > to me to return a CDI > instance, which is a more user-friendly API (and > it also exposes access to > BeanManager) > - is there a usecase for arbitrary keys of the > "params" map or is > Map sufficient? > - if we could move the shutdown() method from > CDIContainer to the actual > container handle that we obtain from initialize(), > that would look more > object-oriented > - what exactly is initialize() supposed to do? Is > it supposed to start > scanning the entire classpath for CDI beans? That > could be a problem > especially with spring-boot-like fat jars. I think > we need an API to tell > the container which classes / packages to > consider. Something like Guice's > binding API perhaps? > > - the proposal makes me wonder whether > retrofitting this functionality to > the CDI class wouldn't be a better option. It > could look like: > > CDI container = CDI.initialize(); > container.select(Foo.class).get(); > container.shutdown(); > > compare it to: > > CDIContainer container = CDIContainerLoader. > getCDIContainer(); > BeanManager manager = container.initialize(); > manager.getBeans(...); > container.shutdown(manager); > > > On 02/10/2015 06:58 PM, John D. Ament wrote: > > All, > > I have the updated API here, and wanted to solicit > any final feedback > before updating the google doc and spec pages. > > > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > > Let me know your thoughts. > > Thanks, > > John > > > _______________________________________________ > 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/20150227/cc9f6380/attachment-0001.html From issues at jboss.org Fri Feb 27 03:09:48 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 27 Feb 2015 03:09:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans In-Reply-To: References: Message-ID: Martin Kouba created CDI-508: -------------------------------- Summary: Nested classes except for static nested classes should not be managed beans Key: CDI-508 URL: https://issues.jboss.org/browse/CDI-508 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans. *3.1.1. Which Java classes are managed beans?* is confusing: {quote} A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: * It is not a *non-static inner class*. {quote} # a *top-level* Java class is never nested # term *non-static inner class* is inaccurate, static nested classes are not inner -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Feb 27 03:20:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 27 Feb 2015 03:20:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-508: ----------------------------- Description: The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans. *3.1.1. Which Java classes are managed beans?* is confusing: {quote} A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: * It is not a *non-static inner class*. * It is a concrete class, or is annotated @Decorator. * ... {quote} # A *top-level* Java class is never nested # Term *non-static inner class* is inaccurate, static nested classes are not inner # It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract... was: The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans. *3.1.1. Which Java classes are managed beans?* is confusing: {quote} A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: * It is not a *non-static inner class*. {quote} # a *top-level* Java class is never nested # term *non-static inner class* is inaccurate, static nested classes are not inner > Nested classes except for static nested classes should not be managed beans > --------------------------------------------------------------------------- > > Key: CDI-508 > URL: https://issues.jboss.org/browse/CDI-508 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans. > *3.1.1. Which Java classes are managed beans?* is confusing: > {quote} > A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: > * It is not a *non-static inner class*. > * It is a concrete class, or is annotated @Decorator. > * ... > {quote} > # A *top-level* Java class is never nested > # Term *non-static inner class* is inaccurate, static nested classes are not inner > # It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract... -- This message was sent by Atlassian JIRA (v6.3.11#6341) From rmannibucau at gmail.com Fri Feb 27 03:40:34 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 27 Feb 2015 09:40:34 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F01720.3080802@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: sure I fully agree excepted I think introducing yet another API to do the same thing is not good so super tempting to skip it and wait for feedbacks rather than introducing it eagerly. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : > My point is that from the application perspective, the user obtains one > container handle for eventual shutdown (CDIContainer) and then looks up a > different container handle (CDI) that they can use for real work (lookup / > event dispatch / etc.) It would be cleaner if the container gave away a > single handle that can do all of that. > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > Not sure I get how a CDI instance can help. > > But container.getBeanManager() sounds nice is not a shortcut for > CDI.current().getBm() otherwise it looks like duplication to me. > > Can we make container not contextual - dont think so? If so it makes sense > otherwise I fear it doesnt add much. > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a ?crit : >> >> I like the initialize + close() combination and the try-with-resources >> usage. >> What looks weird to me is that at line one you obtain a container handle: >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> CDI.current().getBeanManager() ... >> >> and then at line two you call a static method to perform a container >> lookup :-/ >> >> An API that allows you to use the container handle you already got is way >> better IMO, e.g.: >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> container.getBeanManager() >> >> If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, >> we get this easily. >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> Hi guys >>> >>> why note keeping it simple? >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional >>> map to configure vendor features */)) { >>> CDI.current().getBeanManager().... >>> } >>> >>> Not sure the point having initialize() + having shutdown = close >>> really makes the API more fluent and modern IMO. >>> >>> Also to be fully SE I guess provider() method would be needed even if >>> optional (SPI usage by default): >>> >>> try (CDIContainer container = >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>> { >>> CDI.current().getBeanManager().... >>> } >>> >>> Finally I think having a kind of getInstance shortcut could be a plus for >>> SE: >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>> container.newInstance(MyAppRunner.class /* optional qualifiers */ >>> ).run(args); >>> } >>> >>> Using container to get an instance would create the instance and bind >>> it to the container lifecycle (mainly for predestroy) avoiding this >>> boilerplate code in all main which will surely only be used to launch >>> a soft. >>> >>> wdyt? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> Comments inline >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> sorting" >>>> features. >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >>>> wrote: >>>>> >>>>> Hi John, comments inline: >>>>> >>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>> >>>>> Jozef, >>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>> everyone >>>>> seemed to be in agreement. I think the map is just a safeguard in case >>>>> of >>>>> additional boot options available in some implementations (e.g. I think >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded >>>>> CDI >>>>> boot mode). >>>>> >>>>> No, I am fine with the map. What I am questioning is the type of the >>>>> map. >>>>> Usually, data structures with a similar purpose use Strings as their >>>>> keys. >>>>> This applies to ServletContext attributes, InvocationContext data, >>>>> Servlet >>>>> request/session attributes and others. I am therefore wondering whether >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> Map once we clarify everything. >>>> >>>>> >>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>> preferable >>>>> since there's no easy way to get the the instance, CDI is easier to get >>>>> and >>>>> more aligned with how you would get it. Usually people expect the >>>>> BeanManager to be injected or available via JNDI, neither would be the >>>>> case >>>>> here. >>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API will >>>>> become something that ordinary application developers use to start/stop >>>>> CDI >>>>> in their applications. It therefore cannot be considered an SPI but >>>>> instead >>>>> should be something easy to use. On the other hand, BeanManager is >>>>> definitely an SPI. It is used in extension, frameworks and generally >>>>> for >>>>> integration. Not much by applications directly. Therefore, I don't see >>>>> how >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>>> bootstrap >>>>> API should expose something that makes common tasks (obtaining a >>>>> contextual >>>>> reference and firing and event) easy, which the CDI class does. >>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>> CDI.getBeanManager(). >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> - Is this mostly for new apps or existing? If existing, it's probably >>>> using >>>> some internal API, if new it can use whatever API we give. >>>> - I don't want to return void, we should give some kind of reference >>>> into >>>> the container when we're done booting. >>>> >>>> Agreed, we should not be returning void. >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is a two >>>> step reference. With that said, BeanManager makes more sense to return >>>> here. Another thought could be we invent some new class that has both, >>>> but >>>> that's really redundant. >>>> >>>> Why do you think BeanManager makes more sense here? Especially given the >>>> assumption that application code is going to call this init/shutdown >>>> API, I >>>> don't see BeanManager as making more sense. >>>> >>>> >>>>> >>>>> >>>>> Yes, this is the container start API. Sounds like you have some good >>>>> ideas for things like XML configuration or programmatic configuration, >>>>> both >>>>> of which are being tracked under separate tickets. One idea might be >>>>> for an >>>>> optional param in the map to control packages to scan/ignore, in that >>>>> map. >>>>> >>>>> I am wondering whether this configuration should be something optional >>>>> built on top of the bootstrap API or whether we should consider making >>>>> it >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>>> without >>>>> explicitly defining how it behaves. My implicit assumption of the >>>>> proposal >>>>> is that the container is supposed to scan the entire classpath for >>>>> explicit >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, fire >>>>> extensions, etc. This worries me as this default behavior is far from >>>>> being >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>>> plan to >>>> get that completely into the google doc before opening any spec changes >>>> in a >>>> PR. >>>> >>>>> >>>>> >>>>> We didn't want to over load the CDI interface. It already does a lot. >>>>> This is really SPI code, CDI even though it's in the spi package is >>>>> used in >>>>> a lot of application code. >>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>>>> difficult to know when to use what. >>>> >>>> >>>> The problem is that most CDI (the interface) operations are against a >>>> running container. I think we spoke about leveraging CDIProvider at one >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >>>> realizing it was there). I doubt that most app developers use it >>>> currently, >>>> there's not even a way to get a reference to it that I'm aware of. It's >>>> used by the implementor only. >>>> >>>> I don't think there's a conflict. CDI class would still only provide >>>> methods >>>> to be run against a running container. The difference is that there >>>> would be >>>> additional static methods to get this running container (CDI class) to >>>> you >>>> by starting the container. >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> reason >>>> to define a new class for the same purpose. >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, along >>>> the >>>> lines of: >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> container.initialize(); >>>> ... do work >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> container.shutdown(); >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight on my >>>> part) >>>> >>>> and then later on >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> - It throws an IllegalStateException. >>>> >>>> - The container provides no beans of type CDIContainer, it is managed >>>> outside of the CDI container. >>>> >>>> >>>>> >>>>> >>>>> John >>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >>>>> wrote: >>>>>> >>>>>> Hi John, some thoughts: >>>>>> >>>>>> - instead of using BeanManager it makes more sense to me to return a >>>>>> CDI >>>>>> instance, which is a more user-friendly API (and it also exposes >>>>>> access to >>>>>> BeanManager) >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>>>> Map sufficient? >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>>>> actual >>>>>> container handle that we obtain from initialize(), that would look >>>>>> more >>>>>> object-oriented >>>>>> - what exactly is initialize() supposed to do? Is it supposed to start >>>>>> scanning the entire classpath for CDI beans? That could be a problem >>>>>> especially with spring-boot-like fat jars. I think we need an API to >>>>>> tell >>>>>> the container which classes / packages to consider. Something like >>>>>> Guice's >>>>>> binding API perhaps? >>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this functionality >>>>>> to >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>> container.select(Foo.class).get(); >>>>>> container.shutdown(); >>>>>> >>>>>> compare it to: >>>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>>> BeanManager manager = container.initialize(); >>>>>> manager.getBeans(...); >>>>>> container.shutdown(manager); >>>>>> >>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> I have the updated API here, and wanted to solicit any final feedback >>>>>> before updating the google doc and spec pages. >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 john.d.ament at gmail.com Sat Feb 28 13:05:18 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sat, 28 Feb 2015 18:05:18 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: Maybe I'm misreading, but I don't see us adding another API to do the same thing here - we're introducing new functionality. CDIContainer/Loader on startup/shutdown of the application CDI for runtime usage within the application to interact with the container. John On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau wrote: > sure I fully agree excepted I think introducing yet another API to do > the same thing is not good so super tempting to skip it and wait for > feedbacks rather than introducing it eagerly. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : > > My point is that from the application perspective, the user obtains one > > container handle for eventual shutdown (CDIContainer) and then looks up a > > different container handle (CDI) that they can use for real work (lookup > / > > event dispatch / etc.) It would be cleaner if the container gave away a > > single handle that can do all of that. > > > > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > > > Not sure I get how a CDI instance can help. > > > > But container.getBeanManager() sounds nice is not a shortcut for > > CDI.current().getBm() otherwise it looks like duplication to me. > > > > Can we make container not contextual - dont think so? If so it makes > sense > > otherwise I fear it doesnt add much. > > > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a ?crit > : > >> > >> I like the initialize + close() combination and the try-with-resources > >> usage. > >> What looks weird to me is that at line one you obtain a container > handle: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> CDI.current().getBeanManager() ... > >> > >> and then at line two you call a static method to perform a container > >> lookup :-/ > >> > >> An API that allows you to use the container handle you already got is > way > >> better IMO, e.g.: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> container.getBeanManager() > >> > >> If CDIContainer.newCDIContainer() returns an CDI instance or its > subclass, > >> we get this easily. > >> > >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >>> > >>> Hi guys > >>> > >>> why note keeping it simple? > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional > >>> map to configure vendor features */)) { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Not sure the point having initialize() + having shutdown = close > >>> really makes the API more fluent and modern IMO. > >>> > >>> Also to be fully SE I guess provider() method would be needed even if > >>> optional (SPI usage by default): > >>> > >>> try (CDIContainer container = > >>> > >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). > newCDIContainer()) > >>> { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Finally I think having a kind of getInstance shortcut could be a plus > for > >>> SE: > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { > >>> container.newInstance(MyAppRunner.class /* optional qualifiers > */ > >>> ).run(args); > >>> } > >>> > >>> Using container to get an instance would create the instance and bind > >>> it to the container lifecycle (mainly for predestroy) avoiding this > >>> boilerplate code in all main which will surely only be used to launch > >>> a soft. > >>> > >>> wdyt? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : > >>>> > >>>> Comments inline > >>>> > >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: > >>>> > >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart > >>>> sorting" > >>>> features. > >>>> > >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > >>>> wrote: > >>>>> > >>>>> Hi John, comments inline: > >>>>> > >>>>> > >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: > >>>>> > >>>>> Jozef, > >>>>> > >>>>> Most of what you see there is taken from the original doc, since > >>>>> everyone > >>>>> seemed to be in agreement. I think the map is just a safeguard in > case > >>>>> of > >>>>> additional boot options available in some implementations (e.g. I > think > >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an > embedded > >>>>> CDI > >>>>> boot mode). > >>>>> > >>>>> No, I am fine with the map. What I am questioning is the type of the > >>>>> map. > >>>>> Usually, data structures with a similar purpose use Strings as their > >>>>> keys. > >>>>> This applies to ServletContext attributes, InvocationContext data, > >>>>> Servlet > >>>>> request/session attributes and others. I am therefore wondering > whether > >>>>> there is a usecase for the proposed unbound key signature or not. > >>>> > >>>> > >>>> I think that's more of a placeholder, I was assuming it would be > >>>> Map once we clarify everything. > >>>> > >>>>> > >>>>> > >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was > >>>>> preferable > >>>>> since there's no easy way to get the the instance, CDI is easier to > get > >>>>> and > >>>>> more aligned with how you would get it. Usually people expect the > >>>>> BeanManager to be injected or available via JNDI, neither would be > the > >>>>> case > >>>>> here. > >>>>> > >>>>> If CDI 2.0 targets Java SE then this container initialization API > will > >>>>> become something that ordinary application developers use to > start/stop > >>>>> CDI > >>>>> in their applications. It therefore cannot be considered an SPI but > >>>>> instead > >>>>> should be something easy to use. On the other hand, BeanManager is > >>>>> definitely an SPI. It is used in extension, frameworks and generally > >>>>> for > >>>>> integration. Not much by applications directly. Therefore, I don't > see > >>>>> how > >>>>> the container bootstrap API and BeanManager fit together. IMO the > >>>>> bootstrap > >>>>> API should expose something that makes common tasks (obtaining a > >>>>> contextual > >>>>> reference and firing and event) easy, which the CDI class does. > >>>>> > >>>>> Plus do not forget that BeanManager can be obtained easily using > >>>>> CDI.getBeanManager(). > >>>> > >>>> > >>>> I'm not disagreeing. There's a few things I'd consider: > >>>> > >>>> - Is this mostly for new apps or existing? If existing, it's probably > >>>> using > >>>> some internal API, if new it can use whatever API we give. > >>>> - I don't want to return void, we should give some kind of reference > >>>> into > >>>> the container when we're done booting. > >>>> > >>>> Agreed, we should not be returning void. > >>>> > >>>> - CDI is a one step retrievable reference, where as BeanManager is a > two > >>>> step reference. With that said, BeanManager makes more sense to > return > >>>> here. Another thought could be we invent some new class that has > both, > >>>> but > >>>> that's really redundant. > >>>> > >>>> Why do you think BeanManager makes more sense here? Especially given > the > >>>> assumption that application code is going to call this init/shutdown > >>>> API, I > >>>> don't see BeanManager as making more sense. > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yes, this is the container start API. Sounds like you have some good > >>>>> ideas for things like XML configuration or programmatic > configuration, > >>>>> both > >>>>> of which are being tracked under separate tickets. One idea might be > >>>>> for an > >>>>> optional param in the map to control packages to scan/ignore, in that > >>>>> map. > >>>>> > >>>>> I am wondering whether this configuration should be something > optional > >>>>> built on top of the bootstrap API or whether we should consider > making > >>>>> it > >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec > >>>>> without > >>>>> explicitly defining how it behaves. My implicit assumption of the > >>>>> proposal > >>>>> is that the container is supposed to scan the entire classpath for > >>>>> explicit > >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, > fire > >>>>> extensions, etc. This worries me as this default behavior is far from > >>>>> being > >>>>> lightweight, which CDI for Java SE initially aimed to be. > >>>> > >>>> > >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I > >>>> plan to > >>>> get that completely into the google doc before opening any spec > changes > >>>> in a > >>>> PR. > >>>> > >>>>> > >>>>> > >>>>> We didn't want to over load the CDI interface. It already does a > lot. > >>>>> This is really SPI code, CDI even though it's in the spi package is > >>>>> used in > >>>>> a lot of application code. > >>>>> > >>>>> I would personally prefer to have it all in one place. Having > >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more > >>>>> difficult to know when to use what. > >>>> > >>>> > >>>> The problem is that most CDI (the interface) operations are against a > >>>> running container. I think we spoke about leveraging CDIProvider at > one > >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even > >>>> realizing it was there). I doubt that most app developers use it > >>>> currently, > >>>> there's not even a way to get a reference to it that I'm aware of. > It's > >>>> used by the implementor only. > >>>> > >>>> I don't think there's a conflict. CDI class would still only provide > >>>> methods > >>>> to be run against a running container. The difference is that there > >>>> would be > >>>> additional static methods to get this running container (CDI class) to > >>>> you > >>>> by starting the container. > >>>> > >>>> Either way, I agree that reusing CDIProvider is a must. There is no > >>>> reason > >>>> to define a new class for the same purpose. > >>>> > >>>> > >>>> I expect that my changes in the CDI spec around this will state, along > >>>> the > >>>> lines of: > >>>> > >>>> To retrieve a CDIContainer to launch, do this: > >>>> > >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); > >>>> container.initialize(); > >>>> ... do work > >>>> > >>>> Once you want to shutdown the container, do this: > >>>> > >>>> container.shutdown(); > >>>> > >>>> (we may want to consider implementing AutoCloseable, an oversight on > my > >>>> part) > >>>> > >>>> and then later on > >>>> > >>>> - What happens if I call CDIContainerLocator in an app server > >>>> > >>>> - It throws an IllegalStateException. > >>>> > >>>> - The container provides no beans of type CDIContainer, it is managed > >>>> outside of the CDI container. > >>>> > >>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < > jharting at redhat.com> > >>>>> wrote: > >>>>>> > >>>>>> Hi John, some thoughts: > >>>>>> > >>>>>> - instead of using BeanManager it makes more sense to me to return a > >>>>>> CDI > >>>>>> instance, which is a more user-friendly API (and it also exposes > >>>>>> access to > >>>>>> BeanManager) > >>>>>> - is there a usecase for arbitrary keys of the "params" map or is > >>>>>> Map sufficient? > >>>>>> - if we could move the shutdown() method from CDIContainer to the > >>>>>> actual > >>>>>> container handle that we obtain from initialize(), that would look > >>>>>> more > >>>>>> object-oriented > >>>>>> - what exactly is initialize() supposed to do? Is it supposed to > start > >>>>>> scanning the entire classpath for CDI beans? That could be a problem > >>>>>> especially with spring-boot-like fat jars. I think we need an API to > >>>>>> tell > >>>>>> the container which classes / packages to consider. Something like > >>>>>> Guice's > >>>>>> binding API perhaps? > >>>>>> > >>>>>> - the proposal makes me wonder whether retrofitting this > functionality > >>>>>> to > >>>>>> the CDI class wouldn't be a better option. It could look like: > >>>>>> > >>>>>> CDI container = CDI.initialize(); > >>>>>> container.select(Foo.class).get(); > >>>>>> container.shutdown(); > >>>>>> > >>>>>> compare it to: > >>>>>> > >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); > >>>>>> BeanManager manager = container.initialize(); > >>>>>> manager.getBeans(...); > >>>>>> container.shutdown(manager); > >>>>>> > >>>>>> > >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have the updated API here, and wanted to solicit any final > feedback > >>>>>> before updating the google doc and spec pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> https://github.com/johnament/cdi/commit/ > 2c362161e18dd521f8e83c27151ddad467a1c01c > >>>>>> > >>>>>> Let me know your thoughts. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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/20150228/1d6bc283/attachment-0001.html From rmannibucau at gmail.com Sat Feb 28 16:11:16 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 28 Feb 2015 22:11:16 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: Yes but not the way to get an instance. Even Unmanaged does it. What can be awesome is to have static inject for it: public class Runner { @Inject private static MyMain main; public static void main(String[] arg) { try (CDIContainer c = CDIContainer.newContainer()) { main.doWork(); } } } And not a single additional line :). Le 28 f?vr. 2015 19:05, "John D. Ament" a ?crit : > Maybe I'm misreading, but I don't see us adding another API to do the same > thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with the > container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > wrote: > >> sure I fully agree excepted I think introducing yet another API to do >> the same thing is not good so super tempting to skip it and wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >> > My point is that from the application perspective, the user obtains one >> > container handle for eventual shutdown (CDIContainer) and then looks up >> a >> > different container handle (CDI) that they can use for real work >> (lookup / >> > event dispatch / etc.) It would be cleaner if the container gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a shortcut for >> > CDI.current().getBm() otherwise it looks like duplication to me. >> > >> > Can we make container not contextual - dont think so? If so it makes >> sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >> ?crit : >> >> >> >> I like the initialize + close() combination and the try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you obtain a container >> handle: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to perform a container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle you already got is >> way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >> subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >> optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having shutdown = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method would be needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >> newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance shortcut could be a plus >> for >> >>> SE: >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* optional qualifiers >> */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create the instance and bind >> >>> it to the container lifecycle (mainly for predestroy) avoiding this >> >>> boilerplate code in all main which will surely only be used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the original doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is just a safeguard in >> case >> >>>>> of >> >>>>> additional boot options available in some implementations (e.g. I >> think >> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >> embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am questioning is the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose use Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am therefore wondering >> whether >> >>>>> there is a usecase for the proposed unbound key signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was assuming it would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the instance, CDI is easier to >> get >> >>>>> and >> >>>>> more aligned with how you would get it. Usually people expect the >> >>>>> BeanManager to be injected or available via JNDI, neither would be >> the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container initialization API >> will >> >>>>> become something that ordinary application developers use to >> start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other hand, BeanManager is >> >>>>> definitely an SPI. It is used in extension, frameworks and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. Therefore, I don't >> see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common tasks (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the CDI class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be obtained easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If existing, it's >> probably >> >>>> using >> >>>> some internal API, if new it can use whatever API we give. >> >>>> - I don't want to return void, we should give some kind of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where as BeanManager is a >> two >> >>>> step reference. With that said, BeanManager makes more sense to >> return >> >>>> here. Another thought could be we invent some new class that has >> both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense here? Especially given >> the >> >>>> assumption that application code is going to call this init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds like you have some >> good >> >>>>> ideas for things like XML configuration or programmatic >> configuration, >> >>>>> both >> >>>>> of which are being tracked under separate tickets. One idea might >> be >> >>>>> for an >> >>>>> optional param in the map to control packages to scan/ignore, in >> that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration should be something >> optional >> >>>>> built on top of the bootstrap API or whether we should consider >> making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the entire classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, >> fire >> >>>>> extensions, etc. This worries me as this default behavior is far >> from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially aimed to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before opening any spec >> changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. It already does a >> lot. >> >>>>> This is really SPI code, CDI even though it's in the spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one place. Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) operations are against a >> >>>> running container. I think we spoke about leveraging CDIProvider at >> one >> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >> >>>> realizing it was there). I doubt that most app developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it that I'm aware of. >> It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class would still only provide >> >>>> methods >> >>>> to be run against a running container. The difference is that there >> >>>> would be >> >>>> additional static methods to get this running container (CDI class) >> to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around this will state, >> along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing AutoCloseable, an oversight on >> my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in an app server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type CDIContainer, it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >> jharting at redhat.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more sense to me to return >> a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API (and it also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from initialize(), that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >> start >> >>>>>> scanning the entire classpath for CDI beans? That could be a >> problem >> >>>>>> especially with spring-boot-like fat jars. I think we need an API >> to >> >>>>>> tell >> >>>>>> the container which classes / packages to consider. Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether retrofitting this >> functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It could look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to solicit any final >> feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> https://github.com/johnament/cdi/commit/ >> 2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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/20150228/8ac540d2/attachment-0001.html From anatole.tresch at credit-suisse.com Fri Feb 6 10:23:47 2015 From: anatole.tresch at credit-suisse.com (Tresch, Anatole ) Date: Fri, 06 Feb 2015 15:23:47 -0000 Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like In-Reply-To: References: Message-ID: <71654D7C1E7F6C40B31060C6C584A5DD2B0CDFE6@CHW20013593.ch.ad.hedani.net> Hi James I follow also Antoine and Werner that it makes no sense to just add an annotation due to the reason, that adding such an annotation it would requires also to define the exact functionality. This has severe downsides, or basically is not possible within the CDI scope since: ? there are many different views, what such an annotation should do ? if you interpret it widely (and flexible, which makes sense looking at the variety of possible use cases/requirements), you will end up in a complete additional kind of configuration ?sub-spec?,which would bloat the CDI spec. This is also not necessary, since we can do everything we want without any additions to CDI. Even configuring CDI is no issues, since the SPI (extensions) are so incredibly flexible ;) ? if you define the semantics more constraint, e.g. as suggested (system and env properties), it would render the annotation quite useless, for a lot of legit use cases can not be covered. And even with these env / sys properties many questions are still open (like overriding order, overriding policies to mentions some), which are definitively out of scope for CDI as spec. Looking at Apache Tamaya (http://tamaya.incubator.apache.org ), where I together with some other guys (including Mark and Gerhard from Deltaspike) are trying to define a common, minimalistic, but extensible API/SPI, I think we have all the ingredients for a future and unified approach for this topic. We can with the couple of API artifacts we have defined (e.g. see https://github.com/apache/incubator-tamaya/blob/master/docs/API.adoc ), cover everything, what Deltaspike can do for you today, but also the most complex requirements I am aware of, basically fit into this simple approach there. So I would like to encourage you to join our Apache Project and help to drive Apache Tamaya, so we can increase adoption quickly and then hopefully get enough momentum to make it a JSR. Cheers, Anatole ---------- Forwarded message --------- From: Werner Keil > Date: Fr., 6. Feb. 2015 um 11:22 Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like To: cdi-dev > James, I agree with Antoine as IMHO this would exceed the scope of core CDI a bit. There was a discussion by Anatole Tresch (also member of this EG) about creating a dedicated Configuration JSR (modeled among others also a lot after what DeltaSpike does) but so far JCP officials first and foremost Oracle saw either no need or no resources to do this. Apache Tamaya was a logical result. If that could become a blue-print or initial contribution of a future JSR, let's see, maybe for EE 9. It uses other Apache projects like DeltaSpike where applicable, but may also define such annotations and types of its own, so I suggest you also share your ideas on a Tamaya mailing list or JIRA: http://tamaya.incubator.apache.org/index.html On Fri, Feb 6, 2015 at 11:02 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-504) have a standard CDI annotation like @ConfigProperty from deltapsike (James Strachan (JIRA)) 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (Martin Kouba (JIRA)) 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (John Ament (JIRA)) 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (James Strachan (JIRA)) 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (James Strachan (JIRA)) 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (James Strachan (JIRA)) 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA)) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST) From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 James Strachan created CDI-504: ---------------------------------- Summary: have a standard CDI annotation like @ConfigProperty from deltapsike Key: CDI-504 URL: https://issues.jboss.org/browse/CDI-504 Project: CDI Specification Issues Issue Type: Feature Request Reporter: James Strachan Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. Delta Spike as a @ConfigProperty annotation which works very nicely http://deltaspike.apache.org/documentation/configuration.html you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 2 Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST) From: "Martin Kouba (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038005#comment-13038005 ] Martin Kouba commented on CDI-504: ---------------------------------- What's wrong with {{java.lang.System.getProperty()}} and {{java.lang.System.getenv()}}? I mean the main advantage of DS Configuration is IMO the resolution mechanism and the ability to extend the set of {{ConfigSource}} s. If you only need system properties and env variables a simple producer method and qualifier (or even a simple util method) would be sufficient. In other words I see no reason to standardize this. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 3 Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST) From: "John Ament (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038007#comment-13038007 ] John Ament commented on CDI-504: -------------------------------- A separate config JSR has been proposed previously to address this. They want to see more options before trying to standardize it. > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 4 Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST) From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan commented on CDI-504: ------------------------------------ @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert to a String with error handling.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 5 Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST) From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM: ------------------------------------------------------------- @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). was (Author: jastrachan): @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert to a String with error handling.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 6 Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST) From: "James Strachan (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038012#comment-13038012 ] James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM: ------------------------------------------------------------- @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} int bar; @Inject Foo() { barText = System.getenv("FOO"); if (barText == null) { barText = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... bar = someConvertCode(barText); } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Note that in the second case, folks could use the constructor explicitly without being bound to environment variables too; much cleaner, more modular code. Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). was (Author: jastrachan): @Resource is supported - injecting values from JNDI. I don't see why injecting values (with a default value) from the environment isn't also supported too. There's a Java API for JNDI too so folks could look stuff up in JNDI by hand and do the type conversions - but we've injection for those values. Its also much cleaner code and can easily deal generically with type conversion to long/double/float/date etc. Compare: {code} @Inject Foo(int bar, ...) { bar = System.getenv("FOO"); if (bar == null) { bar = "someDefault"; } // now convert the String to an int with nice error handling and reporting.... } {code} to just: {code} @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) { } {code} Also by using an annotation it means its very easy to generate documentation and tooling. (e.g. using APT you can know what all the environment variables are used by CDI; either to report on demand or to generate user documentation). > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ Message: 7 Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST) From: "Antoine Sabot-Durand (JIRA)" > Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike To: cdi-dev at lists.jboss.org Message-ID: > Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038271#comment-13038271 ] Antoine Sabot-Durand commented on CDI-504: ------------------------------------------ James, I don't get what's the problem with using DeltaSpike config solution? > have a standard CDI annotation like @ConfigProperty from deltapsike > ------------------------------------------------------------------- > > Key: CDI-504 > URL: https://issues.jboss.org/browse/CDI-504 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: James Strachan > > Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world). > So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI. > Delta Spike as a @ConfigProperty annotation which works very nicely > http://deltaspike.apache.org/documentation/configuration.html > you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default. > Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation. > Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties. > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese") > There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess. -- This message was sent by Atlassian JIRA (v6.3.11#6341) ------------------------------ _______________________________________________ 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 51, Issue 9 ************************************** _______________________________________________ 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/20150206/750b63c3/attachment-0001.html