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
