Am 18.02.2015 um 12:02 schrieb arjan tijms <arjan.tijms(a)gmail.com&gt;: Hi, On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

1 BM by jar is quickly broken because you can write any lib (too restricted visibility) + "jar" sometimes doesnt mean anything (but deployment does).

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 <arjan.tijms(a)gmail.com&gt;: > > Hi, > > On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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<Class<?>> via @Observes ProcessAnnotatedType. And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: > > > 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 <arjan.tijms(a)gmail.com&gt;: >>> >>> Hi, >>> >>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Am 18.02.2015 um 17:39 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: 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<Class<?>> via @Observes ProcessAnnotatedType. > And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >> >> >> 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 <arjan.tijms(a)gmail.com&gt;: >>>> >>>> Hi, >>>> >>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Am 19.02.2015 um 09:48 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: 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 <jharting(a)redhat.com&gt;: >> >> 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<Class<?>> via @Observes ProcessAnnotatedType. >>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>> >>>> >>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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 <jharting(a)redhat.com&gt;: > > 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 <jharting(a)redhat.com&gt;: >>> >>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>> >>>>> >>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

> 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 <jharting(a)redhat.com&gt;: > > 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 <jharting(a)redhat.com&gt;: >>> >>> 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 <jharting(a)redhat.com&gt;: >>>>> >>>>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>>>> >>>>>>> >>>>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

+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 <rmannibucau(a)gmail.com&gt;: > > 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 <struberg(a)yahoo.de&gt;: >>> 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 <jharting(a)redhat.com&gt;: >>> >>> 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 <jharting(a)redhat.com&gt;: >>>>> >>>>> 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 <jharting(a)redhat.com&gt;: >>>>>>> >>>>>>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>>>>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>> >>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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@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 <rmannibucau(a)gmail.com&gt;: > > 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 <struberg(a)yahoo.de&gt;: >> +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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

+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 <rmannibucau(a)gmail.com&gt;: > > 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 <struberg(a)yahoo.de&gt;: >>> 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 <jharting(a)redhat.com&gt;: >>> >>> 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 <jharting(a)redhat.com&gt;: >>>>> >>>>> 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 <jharting(a)redhat.com&gt;: >>>>>>> >>>>>>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>>>>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>> >>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Am 20.02.2015 um 09:22 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: 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 <jharting(a)redhat.com&gt;: >> >> 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 <jharting(a)redhat.com&gt;: >>>> >>>> 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 <jharting(a)redhat.com&gt;: >>>>>> >>>>>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>>>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>>>>> >>>>>>>> >>>>>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>> >>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

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 <jharting(a)redhat.com&gt;: >> >> >> 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 <jharting(a)redhat.com&gt;: >>>> >>>> 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 <jharting(a)redhat.com&gt;: >>>>>> >>>>>> 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 <jharting(a)redhat.com&gt;: >>>>>>>> >>>>>>>> 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<Class<?>> via @Observes ProcessAnnotatedType. >>>>>>>>> And in @Observes AfterBeanDiscovery we create Bean<T> 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 <jharting(a)redhat.com&gt;: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 <arjan.tijms(a)gmail.com&gt;: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)yahoo.de&gt; 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(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>>> >>>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>> >>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.