Project: springxd
Issue XD-718: Use ParentLastClassLoader to create the Modules ApplicationContext.
The ParentLastClassloader is located in the spring-hadoop project. It will resolve classes first looking at the child context and then the parent. This works well for XD since the we want and dependencies of the module to be considered first and if not found, resolve against the parent. It would be possible to even include other versions of .jars already in the parent classloaders (e.g. Spring Integration jars), but for now, we will not immediately test that case. SimpleModule needs to change to that we can pass in the classloader to use for creating the application context. The current implementation creates a GenericApplicationContext as a field initializer...that should change to be in the ctor. ModuleDeployer should implement .BeanClassLoaderAware. The classloader passed in to the BeanClassLoaderAware callback will be used as the ‘parent’ when creating the ParentLastClassloader. The URL[] to pass into ParentLastClassloader should be ‘null’ or an empty array in this case of an older style module. (Hopefully ParentLastClassloader allows that type of fallback). *Implementation Suggestions:* The ModuleDeployer code is where the application context for the module is defined and instantiated. Here is a possible impl path. 1. Assuming we can always use ParentLastClassloader (even for older style modules), then the ModuleDescriptor needs to return an array of URL[] locations for the module, getURL(). This is passed into the cto for SimpleModule. The ctor then creates a new application context, creates the parentclassloader, sets the classloader on the application context and then proceeds as normal. 2.AbstractModuleRegistry should try and load the resource from two possible locations, e.g. ./modules/source/file/config/file.xml or ./modules/source/file.xml The module registry needs to be a bit smarter to know, ah, i see a config directory, let me try ./config/file.xml otherwise just ./file.xml *How to verify it works.* 1. JUnit test in which one of the ModuleRegistry implementations points to a test directory that contains both old and new style modules. FileModuleRegistry is probably a good choice here. Need to test that the new getting for URL[] works as expected. 2. Existing tests should run as they did before, in particular the shell integration tests.
Story points: 5