jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <Felix.Meschber...@day.com>
Subject Classloaders and extensions
Date Fri, 16 Dec 2005 14:09:58 GMT

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 ?

Felix Meschberger

View raw message