Plug-in API improvements
Support for external plug-ins
External plug-ins are implemented by a code outside the GraphDB's classpath and loaded through their own dedicated class loaders.
They are packaged in plugin directories and grouped into one or more plugin home directories. Every plugin home directory may contain any number of plugin directories, each of which may contain any number of JAR files. A dedicated class loader is created for loading the code from each plugin directory. Every plugin should provide in its plugin directory all dependencies that cannot be expected to be provided through the GraphDB's classpath.
Ideally, a single plug-in directory should provide the implementation of a single plug-in – this is recommended, but not enforced by the current implementation.
Class-loading and plug-in dependencies
In order to allow you maximum freedom, each external plug-in is loaded in a self-first class loader (contrary to the Java's parent-first). It means that the external plug-ins can use whatever dependencies they want, including such that override the ones of GraphDB.
There is one limitation, though. The Java ecosystem is full of various frameworks, which do class instantiation based on reflection or custom class loaders. Be aware of the class-loading in the frameworks you use (think Spring, slf4j, GATE, XML libraries, even Lucene) in order to prevent _ClassCastException_s and _LinkageError_s. Usually, the issue is that a dependency is using the current thread's context class loader, which is actually the GraphDB class loader (since webapp containers run each webapp in its own thread pool and class loader) and this, unfortunately, allows mixing plug-in and core dependencies.
Here is a list of plug-ins, which were previously shipped within OWLIM and have been externalized in order to cut the core's dependency on Lucene.
Skip to end of metadata Go to start of metadata