Hi,

We have written a fully functional Java class loader, which is capable of loading classes from a JCR repository. In its current state it has the following functionality support:

   * Load classes and access resources from the repository.
   * Classes and resources may be stored directly in the repository
     (think of it like a file system classes directory) or in JAR or
     ZIP archives located in the repository.
   * For JAR files, the extraction of the Manifest and definition of
     Package instances are supported.
   * Functionality to observe changes in the repository content of
     loaded classes and marking the class loader as dirty to support
     recreation of the class loader and thus adaption to changed code.
     This is very helpfull during the development of web applications
     where you can simple replace the class loader in case you change
     classes and libraries.

As a first application of the repository class loader we built a simple extension (or plugin) framework, which enables applications to extend themselves with easily deployable functionality. At the core of the extension framework is an ExtensionManager, which is capable of collecting and instantiating extensions and providing them to applications. An extension under the extension framework has the following attibutes:

   * Extension Type (string) - A unique identifier to group together
     extensions with the same functionality. For example, if there
     would be an applications handling certain node types in a specific
     ways, there could be a group of extensions each supporting a
     different node type. The application would instruct the
     ExtensionManager to collect all extensions of this node type
     support extension. The extension type name should of course be
     unique amongst all applications running on the same repository
     workspace (the ExtensionManager is bound to a single workspace
     through the Session used to instantiate the ExtensionManager).
   * Extension Name (string) - A name identifying the extension. To
     continue the above example, the names of the extensions could
     identify the node type they are capable of supporting. The names
     of the extensions must be unique amongst the set of extensions of
     the same type.
   * Class (string) - The fully qualified name of a class implementing
     the extension. There is no restriction on the API to be
     implemented by the extension classes, except that a public default
     constructor must be available for the ExtensionManager to be
     capable instantiating the class.
   * ClassPath (string, multi-value) - A list of resource paths
     identifiying the classpath required for the extension (See below)
   * ConfigurationClass (string) - The fully qualified name of a class
     implementing the Jakarta Commons Configuration interface, which
     provides configuration to the extension. The extension framework
     contains classes supporting loading XML and Properties files from
     the repository. Another class is capable of representing part of
     the repository as an instance of the commons configuration
     HierarchicalConfiguration class. This latter class is also the
     default configuration class used if non is configured.
   * Configuration (child node) - Accessible for example by the class
     configured in the ConfigurationClass property.

The attributes of the extension are reflected in the repository with mixin node type.

Deployment of the extensions would be very easy, as the libraries and classes required to implement the extension as well as the configuration could all be packaged together and deployed into the repository, from where the application can pick up the extensions.

Classloading: The ExtensionManager creates a repository class loader for each extension type (all extensions of the same type share the same class loader), which is configured with the class path of the extensions as they are loaded (This is why the class path is a list of repository paths). When the extension class is instantiated it is loaded through the extension type's class loader. This provides the functionality to deploy the extensions together with their required classes and hence get the classes on demand without having to stop-reconfigure-start the system.

We are considering releasing both to the community as contributions to the Jackrabbit project. What do you think ?

Regards
Felix Meschberger
Day

Reply via email to