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

Am 01.12.2016 um 08:57 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: 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(a)redhat.com&gt; > To: Matej Novotny <manovotn(a)redhat.com&gt;, Benjamin > Confino/UK/IBM@IBMGB, > Cc: Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB, > weld-dev(a)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(a)uk.ibm.com&gt; >>> To: weld-dev(a)lists.jboss.org >>> Cc: "Tom Evans" <TEVANS(a)uk.ibm.com&gt;, "Emily Jiang" <EMIJIANG(a)uk.ibm.com&gt; >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev