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

[Martin Kouba]

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
>