jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Ritchy <rob...@jarbo.com>
Subject Re: Classloaders and extensions
Date Sat, 17 Dec 2005 00:07:38 GMT
This seems like an excellent idea to me and I hope it becomes available 
to this community. Having the ability to publish a versioned 
upgrade/extension sounds really slick. Not only could you associate 
meta-data with jar/zip/class files (for complete accounting of a 
particular users version of a product) - but you could revert upgrades 
with ease.

And, having this working in a JSR170 repo is much better than assuming 
that subversion is installed locally. I'd never bundle subversion with 
my work - but already ship jackrabbit jars with my apps.

I'd definitely check this out - very exciting.


Felix Meschberger wrote:

> 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

View raw message