On Fri, Apr 17, 2009 at 3:34 PM, Simon Laws <[email protected]> wrote: > On Fri, Apr 17, 2009 at 11:58 AM, Simon Laws <[email protected]> > wrote: >> On the issue of finding the correct classloader in the case where >> there are more than on war in an ear. >> >> It may not be a problem in the case that the ear is not sca enhanced >> as the spec doesn't talk about exposing references from wars in this >> case. Don't know if this is a spec issue or not. >> >> It still looks like a problem in the case where the ear is sca >> enhanced as it does imply that war references can form part of the >> component type in this case. >> >> Simon >> > > Ok, so here is a more detailed description of a scenario of the type > that is causing me to think about how to find the right classloader... > > my.jar - a contribution > EARAppcompNestedImplicit.ear > EJBNested.jar/ > META-INF/ > ejb-jar.xml > MANIFEST.MF > packagea/ > ServiceA.class > ServiceAImpl.class > WAR1Nested.war/ > META-INF/ > MANIFEST.MF > classpath=EJBNested.jar > WEB-INF > Web.xml > lib/ > classes/ > packageb > ServletA.class > has reference "serviceReference" of type ServiceA.class > tags/ > page1.jsp > WAR2Nested.war/ > META-INF/ > MANIFEST.MF > classpath=EJBNested.jar > WEB-INF > Web.xml > lib/ > classes/ > packageb > ServletA.class > has reference "serviceReference" of type ServiceA.class > tags/ > page2.jsp > META-INF/ > application.xml > application.composite > <component name="componentA"> > <implementation.web web-uri="WAR1Nested.war"/> > <reference name="serviceReference"> > <interface.java interface="packagea.ServiceA"/> > </reference> > </component> > > <component name="componentB"> > <implementation.web web-uri="WAR2Nested.war"/> > <reference name="serviceReference"> > <interface.java interface="packagea.ServiceA"/> > </reference> > </component> > > <reference name="reference1" > promotes="componentA/serviceReference"/> > <reference name="reference2" > promotes="componentB/serviceReference"/> > > myContribution.contribution > <component name="TopLevelComponent"> > <implementation.jee archive="EARAppcompNestedExplicit.ear"/> > <reference name="reference1" target="someOtherComponentService"> > <interface.java interface="packagea.ServiceA"/> > </reference> > <reference name="reference2" target="someOtherComponentService"/> > <interface.java interface="packagea.ServiceA"/> > </reference> > </component> > > Can I rely on the reference types (packagea.ServiceA in this case) > being in the EAR so that I never have to look in the appropriate WAR > classloader for them? > > The Tuscany runtime is currently coded to resolve interface > definitions against THE contribution or its imports. It takes no > account of a situation where the interface may have to be looked up in > the context of the component/contract that it describes. To the extent > that the interface model in question has no clue about which > component/contract it belongs to and classloading only operates at the > contribution level. > > I could of course go in probably pass more information about to look > up a module/classloader based on the name of the reference and hence > find the correct WAR that is providing the reference. However I'm a > little nervous that the JEE people are going to say that typically the > interface class will be in the ear anyhow so you don't need to bother > with this. The question is does typically = exclusively. Looking for > some help from JEE people here. > > Simon >
Is a jar containing nested ear's and war's really a valid thing? We were just discussing jar's containing jar's last week and ruled them out. ...ant
