On Wed, Apr 15, 2009 at 5:50 PM, Raymond Feng <[email protected]> wrote: > Let's take an example: an ear file (helloworld.ear) containing a web module > and ejb module. The application.composite is follows: > > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; > targetNamespace="http://sample"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > name="Helloworld-web"> > <component name="helloworldWebComponent"> > <implementation.web web-uri="helloworld-web.war" /> > <reference name="helloworldSca" > target="helloworldEjbComponent/HelloworldService"> > <interface.java interface="hello.HelloworldService"/> <!--A --> > </reference> > </component> > <component name="helloworldEJBComponent"> > <implementation.ejb ejb-link="helloworld-ejb.jar#HelloworldEJB" /> > <service name="HelloworldEJB"> > <interface.java interface="hello.HelloworldService"/> <!--B --> > </service> > </component> > </composite> > > I don't think the EAR itself can contain java classes. The java classes will > be packaged inside WARs, EJB jars or utility jars. > > 1) How do we expect A to be loaded? From helloworld-web.war (WEB-INF/classes > and WEB-INF/lib/*.jar, also following the ClassPath entry in MANIFEST.MF)? > 2) How do we expect B to be loaded? From helloworld-ejb.jar (also following > the ClassPath entry in MANIFEST.MF)? > > It seems that there is a context (such as the WAR or EJB jar) to resolve the > java types. > > Thanks, > Raymond > snip...
I think you are right that there is context to help us, for example, as Vamsi points out, OpenEJB that Tuscany is using to perform the JEE archive introspection builds a classloader hierarchy to reflect the JEE archive structure (as you might expect). However I'm going to push you on what you mean by context here. Do you mean TCCL type of context? We are faced with a number of scenarios depending on how the JEE archive is packaged (See the Archive Location Scenarios section of [1]). When may, for example, have a JEE archive that itself is a contribution (E) or the JEE archive may be embedded in a contribution (B). We have to provide a mechanism whereby we can explicitly get at the context. So, some points derived from what Vamsi said... 1. We know that all container classloaders are not created equal so we need some API to allow an integrator to return the archive classloader back to the SCA resolution code e.g. we could push it into the WebModuleInfoImpl/EarModuleInfo/JavaEEApplicationInfo objects that contribution-jee supports 2. We need to integrate this context with the contribution classloader. At the moment it doesn't find the class in the current contribution or in any imports e.g. we could create a new contribution classloader that knows how to deal with JEE class loader hierarchies 3. In dealing with the JEE classloaders we need to be smart about how we find a class. The model resolver is just doing a class for name but we have to start at various parts of the JEE classloader hierarchy as we don't necessarily know whether the class we are looking for is in an EJB/util jar or in on of the web apps. e.g. we could just look until we find it or run out of classloaders but I don't know how you find the web app classloaders unless you are explicitly given them. 4. Assuming we are going to go on and build and start the model we have to make sure that we get the runtime classloaders that the container is using to actually load the JEE classes for real. Not sure precisely what we can do about this other than provide suitable APIs such that the container runtime can provide this info. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
