This seems like an excellent idea to me and I hope it becomes available
to this community. Having the ability to publish a versioned
upgrade/extension sounds really slick. Not only could you associate
meta-data with jar/zip/class files (for complete accounting of a
particular users version of a product) - but you could revert upgrades
with ease.
And, having this working in a JSR170 repo is much better than assuming
that subversion is installed locally. I'd never bundle subversion with
my work - but already ship jackrabbit jars with my apps.
I'd definitely check this out - very exciting.
-Robert
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 ?
Regards
Felix Meschberger
Day
