[cdi-dev] Extension handling in EARs

Romain Manni-Bucau rmannibucau at gmail.com
Wed Feb 18 10:54:30 EST 2015


@jozef: if you get interceptors for instance from an injected bm you dont
get your app ones but jar ones even from a war which breaks comon usages as
well as classloader design where location doesnt mean anything for cdi.
 Le 18 févr. 2015 16:48, "Mark Struberg" <struberg at yahoo.de> a écrit :

> Again, just trying to understand how it works in Weld.
>
> Lets do the following example: MessageBundleExtension in DeltaSpike [1].
>
> We have an
> public interface @MessageBundle MsgInEar { .. }
> in a shared ear lib jar and a second one
> public interface @MessageBundle MsgInWar { .. }
> in WEB-INF/classes of war1.
>
> In Weld there is only 1 instance of the MessageBundleExtension for the
> whole EAR, right?
>
> This extension first collects all the classes annotated with
> @MessageBundle in a Set<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 at redhat.com>:
> >
> >
> > On 02/18/2015 03:19 PM, Mark Struberg wrote:
> >> I fear the clash in bean names across different WARs is a bug which is
> the direct consequence of Weld only has 1 ‚User BeanManager‘. It seems
> there are multiple kind of BeanManagers in Weld. The one that Jozef already
> describes is the ‚BDA BeanManager‘. But there must be another one.
> > That was an old bug in JBoss AS 7. It is fixed in both WildFly and JBoss
> EAP.
> >>  What happens to all the AfterBeanDiscovery#addBean() beans? Where do
> they get stored in App servers using Weld?
> > That should be an implementation detail. What matters where the bean is
> visible from - i.e. if the bean class comes from a shared lib, it should be
> visible globally whereas if it comes from a war it should not be visible
> from another war.
> >>
> >> What happens to BeforeBeanDiscovery#addScope and
> AfterBeanDiscovery#addContext ?
> >> If I package deltaspike-jsf (which activates the a few JSF related
> Contexts) in one of my WARs, do I get those also for my other WARs? What if
> a 2nd war tries to register the same Context? I guess this is what Romain
> meant when he wanted to treat each WAR as (mostly) isolated unit.
> >>
> >> Arjans experience is only the tip of the iceberg.
> >> @Arjan, I would be interested if you would run your tests against
> TomEE-1.7.2-SNAPSHOT. I expect this is also broken as you added lots of
> workarounds to get it running on Weld. But still would love to know how far
> (or not) portability goes.
> >>
> >>
> >> I do fully agree with „1 Extension instance per Application“ paragraph.
> But the important question is what Appliation means. This is by far not
> clear. The EE spec for example talks about „multiple Applications in an
> EAR“ in some paragraphs (meaning Web-Apps it seems). So both
> interpretations are ok by the strict spec wording.
> >>
> >> Of course, the other approaches have their downsides as well…
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 18.02.2015 um 12:02 schrieb arjan tijms <arjan.tijms at gmail.com>:
> >>>
> >>> Hi,
> >>>
> >>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg at yahoo.de>
> wrote:
> >>>> https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
> >>> Interesting write up!
> >>>
> >>> Over at OmniFaces we had some major issues with this as well, and
> >>> blogged about that experience a little over a year ago. See
> >>>
> http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
> >>>
> >>> We also compiled an overview of what works and doesn't work with CDI
> >>> and ears from our perspective here:
> >>> https://github.com/omnifaces/omnifaces/wiki/Known-Issues-(CDI)
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>> There was a lively discussion on twitter but 140 chars is way too
> restrictive to have a good flow ;)
> >>>>
> >>>> So please lets continue the arguments over here.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> cdi-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150218/7d1182cf/attachment-0001.html 


More information about the cdi-dev mailing list