On Thu, Apr 16, 2009 at 8:47 PM, ant elder <[email protected]> wrote: > > > On Thu, Apr 16, 2009 at 8:46 PM, ant elder <[email protected]> wrote: >> >> >> On Thu, Apr 16, 2009 at 6:04 PM, Simon Laws <[email protected]> >> wrote: >>> >>> 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/ >> >> >> As an FYI aside there is a project call Cargo for manipulating JEE >> artifacts and its just had a 1.0 release, maybe it would help. >> >> ...ant >> >> > > ...and the link is http://cargo.codehaus.org/ > > ...ant > > Thanks for the pointer Ant.
Simon
