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:[EMAIL PROTECTED] > 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 > >
