jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Mazzitelli" <john.mazzite...@jboss.com>
Subject RE: Classloaders and extensions
Date Fri, 16 Dec 2005 14:18:34 GMT
Sounds like a very interesting piece of functionality - I'm actually
going to think about this, I may have some use for this ;-)

+1 to releasing to the community here.

John Mazz  

> -----Original Message-----
> From: Felix Meschberger [mailto:Felix.Meschberger@day.com] 
> Sent: Friday, December 16, 2005 9:10 AM
> To: jackrabbit-dev@incubator.apache.org
> Subject: Classloaders and extensions
> 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