OWLIM-Enterprise on Steroids

Skip to end of metadata
Go to start of metadata
Search
This documentation is NOT for the latest version of GraphDB.

Latest version - GraphDB 6.6

OWLIM Documentation

Next versions

[OWLIM 5.6]
GraphDB 6.0 & 6.1
GraphDB 6.2
GraphDB 6.3
GraphDB 6.4
GraphDB 6.5

Previous versions

OWLIM 5.4
OWLIM 5.3
OWLIM 5.2
OWLIM 5.1
OWLIM 5.0
OWLIM 4.4
OWLIM 4.3
OWLIM 4.2
OWLIM 4.1
OWLIM 4.0

Some of the development paths we take lead us to fascinating new places. Here is the documentation for cool new features which are yet to make it into the official release, but are available in special branch builds.

Plug-in API improvements

These are scheduled to be made available in official OWLIM 5.6.xxxx releases. Until then, builds of 5.4 with the following modifications are available upon request.

Support for external plug-ins

External plugins are implemented by code outside OWLIM's classpath and loaded through their own dedicated class loaders.

External plugins are packaged in plugin directories, grouped into one or more plugin home directories. Each 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. Each plugin should provide, in its plugin directory, all of its dependencies that cannot be expected to be provided through OWLIM's classpath.

Ideally, a single plugin directory should provide the implementation of a single plugin – this is recommended, but not enforced by the current implementation.

Class-loading and plug-in dependencies

In order to allow plug-in developers maximum freedom, we load each external plug-in in a self-first class loader (contrary to Java's parent-first). This means that external plug-ins can use whatever dependencies they want, including such that override OWLIM's.

There is one caveat though. The Java ecosystem is full of various frameworks that do class instantiation based on reflection or custom class loaders. The plug-in developers should be aware of the class-loading in the frameworks they 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 OWLIM class loader (since webapp containers run each webapp in it's own thread pool and class loader) and this allows mixing of plug-in and core dependencies for bad.

To get to the external plug-ins' documentation visit their own page.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.