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
