jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Classloaders and extensions
Date Fri, 16 Dec 2005 14:26:52 GMT
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 ?

Maybe I'm missing something, but what is the advantage of this compared 
to, say, OSGi? Why would I want to store my classes in a content 
repository and why would I want to have half of the wheels of existing 
component solutions reinvented?

Please take these questions not as criticism, but as serious and honest 


View raw message