So, I've put some simple classloader code [1] together to help us understand the issues. Basically it stores classloaders in WarModuleInfo and EjbModuleInfo structures and then introduces an SCA JEE classloader to find the right classes. So back to Vamsi's original proposal/questions...
> Some of the ideas that I have are: > 1. Have the current JavaEE introspection extension point return a class > loader for the archive introspected. > 2. Have an extension point or a utility to return/resolve(?) a class loader > based on the URI of the artifact passed as parameter. I took approach 1 here but current the module info structures already return JEE classes read from the same classloader so returning the classloader itself seems to unbalance the interface somewhat. Having access to the separate classloader may allow a solution to the deploy vs build problem described later but at the moment the new classloader interface is used at the "resolve" phased which is as close to the "read" phase as makes no difference. > Then create a new ContributionClassLoaderProvider to override the default one > incase the runtime supports Java EE implementation types. Currently the DefaultContributionClassLoaderProvider is not picked up via the utility extension point so I removed it. This does allow me to exploit this extension point to install the JEEClassLoaderProvider but we then couldn't add anything else in the future. Not ideal but OK for now. > Another aspect that we need to consider is that incase of EAR application, > there are multiple classloaders at play, like the Application > classloader with common libraries, EJB classloader with all EJB modules in > the EAR and one classloader per web module. So, the > contribution classloader will have to manage more than one classloader under > the covers and delegate class loading to appropriate class loader. How to tell which classloader to delegate to? The answer may be that the class resolution is being performed in the context of a component whose implementation resolves to a JEE archive (or something in a JEE archive). However down in the Java class resolution code it doesn't have this context. Also if we have an EAR with multiple WARs which each expose references then how to know which SCA reference relates to which WAR. It may be that there is enough info in the component type structure to associate a reference with a WAR. I haven't looked yet. But even if this is the case we would need to be able to feed this through the interface.java resolution logic which is somewhat independent at the moment. At the moment my code just looks at the modules in turn but of course there may be the case that two modules contain the same class. More investigation required. > During the build phase, the Java EE introspection code may be creating > temporary classloaders (like OpenEJB does at the moment) to obtain > the metadata required for deployment. And at runtime the classloaders are > different and in most cases the classes are available in the thread > context classloader. This could be really problematic. The code at the moment assumes that the classes used to construct the component type are the classes used at runtime in the binding and wire processing. I don't know what the proposal is in terms of actually interacting with the runtime is but I would have to assume that the SCA runtime will be dealing with classes that the JEE runtime is also dealing with. I don't see how you would make it work without this. So I can see that it is useful to do contribution testing with OpenEJB standalone but wouldn't this be performed by the container if we have an active container. It might be using OpenEJB also but if what you are saying is that OpenEJB creates these classloads in the knowledge that it is going to create some more to actually load and run the JEE artifacts then we have a problem. II think we need to find a way of getting the runtime classloaders at component type creation time. > It becomes more complicated in the case of nested EARs (i.e., an EAR > contribution packaging another EAR inside). One way I can think of > > handling this is by viewing the contribution as a heirarchy of logical > contributions and having implicit imports. We may need a magic JEE import anyhow as this would help us with the external JEE archive scenario. So worth investigating. Simon [1] http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/contribution-jee-impl/src/main/java/org/apache/tuscany/sca/contribution/jee/impl/
