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 > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
