jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: Classloaders and extensions
Date Fri, 16 Dec 2005 14:28:26 GMT
Hi felix

 I'd like to take a look at it. Please don't take it wrong but the
proposal made me think of a proposal sent to the incubator a few
months ago. see
http://mail-archives.apache.org/mod_mbox/incubator-general/200507.mbox/%3c42E11D57.1030306@odoko.co.uk%3e

br,
edgar

On 12/16/05, Felix Meschberger <Felix.Meschberger@day.com> 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
>
>

Mime
View raw message