Spring jar auto-loading

Question

My project uses a simple plugin mechanism based on multiple application contexts defined in plugin jars. However for this to work i have to include all of the plugin jars on the classpath. It would be nice if Spring could automatically load jars and containing components on it's own which are for example placed in the 'plugins' subdirectory of my project.

Is there some solution for this?

---

I went a bit furtherer and tried to solve this with Jar Class Loader.

Because i'm instantiating the Spring application context manually i can do the following:

GenericApplicationContext ctx = new GenericApplicationContext();

// Load context definitions from plugin jars
JarClassLoader jcl = new JarClassLoader();
jcl.add("plugins/");

XmlBeanDefinitionReader classPathBeansReader = new XmlBeanDefinitionReader(ctx);
classPathBeansReader.setBeanClassLoader(jcl);
classPathBeansReader.setResourceLoader(new PathMatchingResourcePatternResolver(jcl));
classPathBeansReader.loadBeanDefinitions("classpath*:META-INF/my-plugins-*.xml");

However this is not working. From Spring's log i can see that it doesnt read the XML definition in the plugin jar. If i replace the bottom block with

XmlBeanDefinitionReader classPathBeansReader = new XmlBeanDefinitionReader(ctx);
classPathBeansReader.setBeanClassLoader(jcl);
classPathBeansReader.loadBeanDefinitions(new ClassPathResource("META-INF/my-plugins-somemodule.xml",jcl));

it finds and loads the XML definition file and beans from the jar. However this way i'm hardwiring the XML resource name for one plugin, which i don't wan't. How can i make the pattern matching working with JCL?

Answer 1

You might like to consider using OSGi as your plugin loading mechanism.

The Eclipse Virgo open source project provides an OSGi runtime environment that is suited to your project because it has Spring built in. Virgo offers Tomcat and Jetty based servers and a standalone kernel which can be used on its own or to construct other types of server. See the Virgo web site for features and benefits.

OSGi has quite a different design point than you may be used to in Java. It gives you controlled isolation between plugins, known as bundles, unlike a linear classpath. Bundles are wired together in a dependency graph and support versioning and dynamic life cycle operations.

The preferred means for a bundle to use the facilities of other bundles is via the OSGi service registry. The Spring DM project enables normal Spring beans to be published to the service registry and looked up from the service registry. Spring DM is also built in to Virgo. Spring DM has been donated to Eclipse as the Gemini Blueprint project.

To use Virgo, you would add some Spring DM configuration to each of your plugins in the META-INF/spring directory. This configuration, which is a normal XML Spring configuration file, can reference beans in your other Spring files and publish those beans in the service registry, or can provide beans for services looked up in the service registry which may then be referenced by, and injected into, beans in your other Spring files.

You would then deploy your plugins into Virgo using any of the supported mechanisms. You could simply drop them in dependency order into the pickup directory. Or you could use the web admin console or shell console to deploy then.

Alternatively, and this would seem to fit your requirement rather well, you could place plugins providing packages for other plugins in the Virgo repository by dropping them into repository/usr and then deploy the plugins which depend (transitively) on the repository plugins via the pickup directory or web admin console. Virgo will automatically deploy the dependencies from the repository as the dependent plugins are deployed.

You could also group plugins together either in an archive, known as a PAR, or by storing them in the Virgo repository and then referencing them in an XML file, known as a plan. You would then deploy the PAR or plan as describe above. You can even put some of the dependencies in the Virgo repository and reduce the PAR or plan to contain just the dependent plugins.

If you would like further information about Virgo, just ask on the Virgo community forum.

Answer 2

It seems that JCL doesn't override ClassLoader#findResource(String)

JarClassLoader.java AbstractClassLoader.java

PathMatchingResourcePatternResolver JavaDocs state:

Internally, this happens via a ClassLoader.getResources() call

JavaDocs for ClassLoader#getResources(String) defers to documentation for ClassLoader#findResource(String), which states:

Finds the resource with the given name. Class loader implementations should override this method to specify where to find resources.

So while my answer is based on just reading a few bits of docs, I'd surmise that JCL doesn't support this due to not overriding the documented methods.

You could test this by subclassing JarClassLoader and implementing findResource(String), to test my hypothesis.

Of course, I could be wildly wrong.