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 <[email protected]> > To: Matej Novotny <[email protected]>, Benjamin > Confino/UK/IBM@IBMGB, > Cc: Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB, > [email protected] > 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" <[email protected]> >>> To: [email protected] >>> Cc: "Tom Evans" <[email protected]>, "Emily Jiang" <[email protected]> >>> 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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> _______________________________________________ >> weld-dev mailing list >> [email protected] >> 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 [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
