[cdi-dev] Extension handling in EARs

[Mark Struberg]

Totally agree that a jar is not a native part of an app. It’s just a random entry in the classpath.
Especially since older Glassfish and JBossAS versions were totally broken in regard to BDA there are still tons of projects who simply unpack all the jars into WEB-INF/classes. 
Also all the projects wo do re-packaging for OSGi related reasonst or ’shading’ into another jar. BDA==JAR just totally didn’t work out. 
And btw this also contradicts section 5 of the CDI spec. As discussed a dozen of times: the CDI spec contradicts itself and has 2 different definitions for ‚BDA‘. And I like the one of paragraph 4 (which basically follows EE module boundaries) way better ;)


LieGrue,
strub

 
> Am 18.02.2015 um 15:29 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> 
> Mark
> 
> seems there are multiple topics and can maybe be better to split them
> accross threads to avoid to cross topics and finally be lost easily.
> 
> Here the ones I see:
> 
> -> BDA BM (what it means, usability in real apps = outside of TCKs) -
> this is also the question of the modularity of CDI. there are few
> pointers in the spec but seems it is only implemented this way in few
> containers. The question of deployment/runtime consistency if
> important as well. 1 BM by jar is quickly broken because you can write
> any lib (too restricted visibility) + "jar" sometimes doesnt mean
> anything (but deployment does).
> -> EAR and bean managers (1 by jar? 1 by sub app? 1 for lib + 1 by
> webapp? 1 for the whole app?)
> -> (if previous answer is not 1 for the whole app) EAR and bean
> propagation/inheritance
> -> same as previous with events (splitting in container events and
> runtime events I think)
> -> EAR and different use cases (1) just a packaging for my app, 2)
> aggregating existing app => both needs different meaning for the same
> scopes relatively quickly :s)
> 
> Hope I was more or less clear on this fuzzy topic
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-02-18 15:19 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
>> 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 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.