[cdi-dev] Extension handling in EARs

Thu Feb 19 16:28:13 EST 2015

yep what's I meant by logical (technically we an do all we want)


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-19 21:10 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> +1
> It’s not only logical, it’s really technically crucial.
>
> Say in war1 you call
>
> beanManager.fire(new ClassWhichOnlyExistsInWar1());
>
> and get this event in war2 where it gets observd (maybe due to a super type or interface). This will just blow up your application.
> That’s broken, broken, broken.
>
> LieGrue,
> strub
>
>
>> Am 19.02.2015 um 20:56 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
>>
>> Agree, the most logical + understandable (=usable) rule is to be
>> aligned to classloading/structure. Breaking this simple rule
>> completely breaks the common usage
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-19 20:54 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
>>>> if you fire(new Object()) in war1, nothing prevents
>>>> it from being delivered also in war2 / ejb jars
>>>
>>> That must not happen.
>>>
>>> Events fired from a class in war1 must only get observed from objects which are visible to it. This is objects from the shared ejb jars but NOT from war2.
>>>
>>>
>>> Please also note that the class of my War1Extension in war1 is only visible in war1. And War2Extension is only visible in war2. So if War1Extension gets classes from war2 and the other way around, then you will get all kinds of nasty NoClassDefFound and ClassNotFoundExceptions. It simply doesn’t work.
>>>
>>> I’ll wrap out the code from my bigger project and will provide it as standalone EAR so you can play with it.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>> Am 19.02.2015 um 16:53 schrieb Jozef Hartinger <jharting at redhat.com>:
>>>>
>>>> On 02/19/2015 03:21 PM, Mark Struberg wrote:
>>>>> I created a small EAR app which has an Extension in a shared ejb jar and another one in a WAR.
>>>>>
>>>>> And as expected it is pretty much non-portable (to avoid the word ‚broken‘).
>>>>> The Extension from the WAR also gets the ProcessAnnotatedType from the classes in the shared lib. And it can also modify those classes (and e.g. add Annotations and Interceptors which classes are only in the WAR). This would be ok if you would like the 1-per-WAR handling, but not in your preferred ‚module‘ handling. The single BeanManager/Extension/Scenario approach of Weld just diametrally conflicts with the modularity claim.
>>>>>
>>>>> It gets even worse: after adding another WAR 2, these classes ALSO get handed to the Extension registered in WAR1…
>>>> Right, this is weird. This is mostly because observer resolution rules do not define any boundaries within an application. (e.g. if you fire(new Object()) in war1, nothing prevents it from being delivered also in war2 / ejb jars). If observer resolution rules defined visibility boundaries similar to those that are effective for bean resolution, it would also solve the problem with extensions.
>>>>>
>>>>> EARs are currently broken in WildFly, JBossAS, WebSphere and TomEE as well to some degrees.
>>>>>
>>>>> We really need to sit down and define what to expect from them. And I fear the 1 Extension per EAR approach is not the best solution…
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>> Am 19.02.2015 um 09:48 schrieb Jozef Hartinger <jharting at redhat.com>:
>>>>>>
>>>>>> OK, getTypes() does not have any effect on this - it's all about getBeanClass(). Let's have two classes:
>>>>>>
>>>>>> A - in a shared jar
>>>>>> B - in a war
>>>>>>
>>>>>> Just for a moment let's assume that these classes are just plain classes that get recognized as simple managed beans. Their visibility would be as follows:
>>>>>>
>>>>>> A - injectable into other beans in shared jars, wars, ejb jars (i.e. visible from everywhere within the EAR)
>>>>>> B - injectable into other beans in the same war. Not injectable to other wars, ejb jars, shared libraries
>>>>>>
>>>>>> So far we'll hopefully on the same page.
>>>>>>
>>>>>> Now let's drop the managed bean assumption and work with extension-provided beans instead. A and B are both bean classes of artificial Bean<?> implementations ABean, BBean respectively, registered by our FooExtension. As Mark already wrote, Weld will create a single instance of FooExtension whose AfterBeanDiscovery callback is invoked once. The question was what happens to ABean and BBean when the extension calls addBean(ABean), addBean(BBean).
>>>>>>
>>>>>> What *does not* happen is storing all the beans in a single bean archive (BeanManager). Instead, for each of the beans Weld identifies the right bean archive (BeanManager) to put the bean into so that bean visibility is respected. Bean.getBeanClass() is used for this purpose. This may result in the bean being put into one of the existing bean archives or in creation of a new logical bean archive and the bean archive graph updated accordingly. The final result is identical with the simple case we started with:
>>>>>>
>>>>>> ABean - is injectable into beans anywhere in the entire EAR
>>>>>> BBean - is not injectable outside of the given war
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Jozef
>>>>>>
>>>>>>
>>>>>> On 02/18/2015 08:49 PM, Mark Struberg wrote:
>>>>>>> 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 at redhat.com>:
>>>>>>>>
>>>>>>>> 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 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.
>