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@uk.ibm.com>

>> To: weld-dev@lists.jboss.org

>> Cc: "Tom Evans" <TEVANS@uk.ibm.com>, "Emily
Jiang" <EMIJIANG@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@lists.jboss.org

>> 
https://lists.jboss.org/mailman/listinfo/weld-dev

>

> _______________________________________________

> weld-dev mailing list

> weld-dev@lists.jboss.org

> 
https://lists.jboss.org/mailman/listinfo/weld-dev

>