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 Sun, 18 Dec 2005 03:29:43 GMT
Hi to all,

Robert Ritchy wrote:
> 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.

I'm very confused with this proposal and I'd like to ask for help to 
understand the scope of it.

Regarding the classloading part the only use case I can think of is 
using it during development, I would try it and if it makes me more 
productive I'm all for it, that's all I need to adhere to a new 
technology during development. But when it comes to distributed 
applications I don't think it's a good idea. What's the difference 
between the case commented by Robert and the imaginary scenario from the 
incubator proposal?. I'm surely missing something here. Could anyone 
shed some light?

And regarding the plugin framework, why would I use my content 
repository as a key player in my component architecture?, is it 
necessary/desirable?, Felix says everything is content, is it?, is it a 
new architecture that one might call Content Oriented Architecture?, has 
it any sense?. IMHO it sounds a little like the soa evangelists 
brochures, but COA in this case. As Stefano pointed we already have 
osgi, but also WS, bpel, jbi, esb, blah, blah. All I need is an 
enterprise jcr repository with all the fancy stuff you can imagine?. The 
soa evangelists already have very decent products and specifications, 
both commercial and os, why would I discard those products in favor of 
using a content repository as a service bus? I don't understand the 
reasoning under the "everything is content" phrase. I'd love to hear 
more opinions about this.

I'd like to make clear that I'm not being ironic nor arrogant, if it 
seems the contrary it's just my poor english skills betraying me.


> 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

View raw message