[cdi-dev] Extension handling in EARs
jharting at redhat.com
Wed Feb 18 09:54:16 EST 2015
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
> 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…
>> Am 18.02.2015 um 12:02 schrieb arjan tijms <arjan.tijms at gmail.com>:
>> On Wed, Feb 18, 2015 at 10:37 AM, Mark Struberg <struberg at yahoo.de> wrote:
>> 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
>> We also compiled an overview of what works and doesn't work with CDI
>> and ears from our perspective here:
>> 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.
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
More information about the cdi-dev