On Fri, Apr 17, 2009 at 8:42 PM, Simon Laws <[email protected]>wrote:
> Ok, well if I can discount the ear as a problematic case due to the > way that ears are naturally structured then the problematic case > becomes one of multiple wars in a contribution. I.e. > > my.jar - a contribution > 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 > > myContribution.contribution > <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> > > > Now I have no idea if we support wars inside a contribution (anyone > care to comment?). I suspect not at the moment. So I would be more > comfortable with documenting a restriction here. implementation.web is to be used only inside a WAR or an EAR. If the WAR is packaged in another contribution, implementation.jee should be used. > A single war in a > contribution or indeed the case where the war is the contribution > don't cause a problem as there is no scope for multi-war classloader > conflicts. > > The promotion case is also OK I think as we only resolve artifacts in > the scope of their immediate contribution and its imports. Anyone see > any flaws in this argument? > > Simon > -- Vamsi
