@Jozef: can't work and you get far more than classnotfound,
noclassdeffound and linkageerror. Or if you support it then isolation
is fully broken and that's afr worse from an app behavior point of
view.
Romain Manni-Bucau
@rmannibucau
No, it won't. The class from war1 loaded by war1 classloader
will
continue to use the same classloader for linkage. The fact that you send
that class as a parameter to a method in a different war (classloader)
does not influence class linkage anyhow.
On 02/20/2015 09:53 AM, Mark Struberg wrote:
> In practice you don’t only have single classes. If your class references another
class in the war in a method then it WILL blow up that way.
>
> LieGrue,
> strub
>
>
>> Am 20.02.2015 um 09:22 schrieb Jozef Hartinger <jharting(a)redhat.com>:
>>
>>
>> On 02/19/2015 08:54 PM, Mark Struberg wrote:
>>>> if you fire(new Object()) in war1, nothing prevents
>>>> it from being delivered also in war2 / ejb jars
>>> That must not happen.
>> We can try to revisit those rules for CDI 2.0
>>> 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.
>> Wrong Mark, this is not how Java classloading works. You get
"NoClassDefFound or ClassNotFound exceptions" if a classloader fails to load or
link a class. What probably confused you in your scenario is that class A from war1 is
loaded by war1 classloader and then passed to an extension loaded by war2 classloader.
That however does not impact how class A is loaded / linked at all. war1 classloader will
still be used to load/link it.
>>> 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(a)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(a)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(a)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(a)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(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.
_______________________________________________
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.