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/[EMAIL PROTECTED]
br, edgar On 12/16/05, Felix Meschberger <[EMAIL PROTECTED]> 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 > >
