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>:
>
> Hi,
>
> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg(a)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(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.