Re: [cdi-dev] Extension handling in EARs

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.