So the following code seems to be at the heart of this...
public class JavaEEModuleHelper {
public AppModule getMetadataCompleteModules(String jarFilePath)
throws ContributionReadException {
DeploymentLoader loader = new DeploymentLoader();
AppModule appModule = null;
try {
appModule = loader.load(new File(jarFilePath));
} catch (OpenEJBException e) {
throw new ContributionReadException(e);
}
// Set the Thread context class loader as the module's class
loader and all the Web and EJB modules
// inside. Otherwise, SCA annotations could not be processed
// TODO: Eliminate the use of reflection for setting the class
loader
java.lang.reflect.Field field = null;
try {
field = appModule.getClass().getDeclaredField("classLoader");
} catch (SecurityException e) {
throw new ContributionReadException(e);
} catch (NoSuchFieldException e) {
throw new ContributionReadException(e);
}
field.setAccessible(true);
try{
field.set(appModule,
Thread.currentThread().getContextClassLoader());
} catch (IllegalArgumentException e) {
throw new ContributionReadException(e);
} catch (IllegalAccessException e) {
throw new ContributionReadException(e);
}
for(EjbModule ejbModule:appModule.getEjbModules()) {
java.lang.reflect.Field field1 = null;
try {
field1 = ejbModule.getClass().getDeclaredField("classLoader");
} catch (SecurityException e) {
throw new ContributionReadException(e);
} catch (NoSuchFieldException e) {
throw new ContributionReadException(e);
}
field1.setAccessible(true);
try {
field1.set(ejbModule,
Thread.currentThread().getContextClassLoader());
} catch (IllegalArgumentException e) {
throw new ContributionReadException(e);
} catch (IllegalAccessException e) {
throw new ContributionReadException(e);
}
}
for(WebModule webModule:appModule.getWebModules()) {
java.lang.reflect.Field field1 = null;
try {
field1 = webModule.getClass().getDeclaredField("classLoader");
} catch (SecurityException e) {
throw new ContributionReadException(e);
} catch (NoSuchFieldException e) {
throw new ContributionReadException(e);
}
field1.setAccessible(true);
try {
field1.set(webModule,
Thread.currentThread().getContextClassLoader());
} catch (IllegalArgumentException e) {
throw new ContributionReadException(e);
} catch (IllegalAccessException e) {
throw new ContributionReadException(e);
}
}
// Process deployment descriptor files
ReadDescriptors readDescriptors = new ReadDescriptors();
try {
readDescriptors.deploy(appModule);
} catch (OpenEJBException e) {
throw new ContributionReadException(e);
}
// Process annotations
AnnotationDeployer annDeployer = new AnnotationDeployer();
try {
annDeployer.deploy(appModule);
} catch (OpenEJBException e) {
throw new ContributionReadException(e);
}
return appModule;
}
}
We're using OpenEJB to create the the module representation of the JEE
app and we are here replacing the classloaders in the resulting model
with TCCL. This is unlikely to have the correct entries on it such
that the contents of the EAR and the WAR and JAR it contains, can be
located. This has apparently worked in the past so I'm a little
confused. May be this holds together in an container environment but
I'm suspicious. I'd like to understand
- what classloaders OpenEJB uses/created by default in the JSE and JEE
environments. In JEE environment I'd expect it to rely on the
containers EAR classloader hierarchy.
- what we think is on the TCCL in this case
- what the comment "Otherwise, SCA annotations could not be processed" means
Anyone have any insights to remove the need to trawl through the code?
Simon
