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

Reply via email to