[weld-dev] Specializes bean in war causes unsatisfied resolution exception

[Martin Kouba]

Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
> Thank you for the prompt replies.
>
> In answer to your question. It is UiSnapshotData which gets injected
> under OWB.

Ok, thanks. From my point of view this violates the EE class loading rules.

>
> Regards
> Benjamin
>
>
>
> From:        Martin Kouba <mkouba at redhat.com>
> To:        Matej Novotny <manovotn at redhat.com>, Benjamin
> Confino/UK/IBM at IBMGB,
> Cc:        Emily Jiang/UK/IBM at IBMGB, Tom Evans/UK/IBM at IBMGB,
> weld-dev at lists.jboss.org
> Date:        29/11/2016 07:42
> Subject:        Re: [weld-dev] Specializes bean in war causes
> unsatisfied resolution exception
> ------------------------------------------------------------------------
>
>
>
> Matej is correct. The specializing bean from the war disables the
> specialized bean from ear/lib. And since the bean from war is not
> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
> unsatisfied dependency exists.
>
> By the way, what instance of SnapshotData gets injected into
> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
> war/lib?
>
> Martin
>
> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>> Hello Benjamin
>>
>> Thanks for well written question!
>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>
>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>
>>> My first thought was that this application should not work
>>
>> I agree with that. Anything located in EAR/lib cannot really "see"
> into WAR.
>> Hence the bean with @Specializes (in WAR) will disable the original
> bean (in EAR/lib) and the injection cannot be performed as
>> the specialized bean is not visible to the archive in EAR/lib.
>>
>>> I confirmed that this application works fine on OpenWebBeans.
>>
>> The fact that it does NOT work should be in accord with Java EE spec
> and its visibility restrictions.
>> Maybe you should be asking OWB guys why does it work at all?
>>
>> I am no EAR expert but I really think this is Java EE spec (not CDI)
> intended behavior.
>>
>> Matej
>>
>> ----- Original Message -----
>>> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>>> To: weld-dev at lists.jboss.org
>>> Cc: "Tom Evans" <TEVANS at uk.ibm.com>, "Emily Jiang" <EMIJIANG at uk.ibm.com>
>>> Sent: Monday, November 28, 2016 4:56:12 PM
>>> Subject: [weld-dev] Specializes bean in war causes unsatisfied
> resolution                 exception
>>>
>>> Hello
>>>
>>> A customer of mine sent in a test application with the following
> structure:
>>>
>>> A war file inside ear
>>> Two jar files inside ear/lib
>>> One jar file inside ear/war/WEB-INF/lib
>>>
>>> There is a class inside one of the ear/lib jar files which @Injects a
> bean
>>> from the other ear/lib jar file
>>>
>>> And there is a class inside the ear/war/WEB-INF/lib jar file that
>>> @Specializes the bean inside an ear/lib jar file
>>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>>
>>> Attempting to run this application on Weld results in an Unsatisfied
>>> Resolution Exception. When I remove the jar containing the
> @Specializes bean
>>> the application works correctly.
>>>
>>>
>>> My first thought was that this application should not work, because
> the war
>>> file and it's internal jar would have a second classloader that would be
>>> invisible to the application classloader. However the customer
> attested, and
>>> I confirmed that this application works fine on OpenWebBeans.
>>>
>>> I do not think this is an integration issue, because I tested this on
> Wildfly
>>> and got the same error.
>>>
>>>
>>> So it seems that Weld throws an Unsatisfied Resolution Exception if
>>> @specializes exists in a class that is loaded by a classloader which
> is not
>>> visible .
>>>
>>> What do you think is the correct behaviour is in this instance? From a
>>> classloading perspective a class inside ear/lib should not be able to
> see a
>>> class inside ear/war; but on the other hand the entire purpose of a
>>> @Specializes bean is that you drop it into your application and it
> replaces
>>> the original bean. It feels appropriate that you can drop in a war file
>>> containing the @Specializes bean and it just works without you having
> to do
>>> anything extra.
>>>
>>> Best regards
>>> Benjamin
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic