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. 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
