cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] The impact of using OSGi
Date Tue, 09 Aug 2005 22:03:48 GMT
Bertrand Delacretaz wrote:
<snip/>
> Last week I tried loading the template block (that Reinhard has hacked 
> to be an OSGI bundle) in OSGI dynamically, after starting without it, 
> but it didn't work, as the cocoon_servlet bundle (IIRC) was looking for 
> some xconf resource from the template block at startup and failed.

The aim with making a bundle of the template block was to test the 
simplest way of implementing blocks with OSGi. The idea is as follows: 
the template block is a passive library bundle (no activator) that 
exports all its packages. The Cocoon core bundle is configured to 
dynamically import all o.a.c packages:

   DynamicImport-Package: org.apache.cocoon.*

This makes it possible for the service manager in the Cocoon core bundle 
to create all components where the classes are installed in the 
framework and that are in o.a.c.**. The implementation don't contain any 
dynamic handling of configurations, IIUC the needed configuration for 
the template block is handled statically of the build system.

Configurations could be handled dynamically by letting the Cocoon 
servlet bundle register a bundle update listener that gets notified each 
time a bundle is installed, updated or uninstalled and checks if the 
bundle contains a configuration file and updates its service manager in 
that case.

Such a system would be a better and dynamic replacement of the compile 
time blocks of today. But it has two important drawbacks: it require 
blocks to export all packages and it makes the block dependent of the 
component manager (ECM++) of the Cocoon core.

The solution with having a per block component manager that publish 
components as OSGi services, that Sylvain is working on makes the system 
much more flexible and scalable. Different blocks can be managed by 
different component managers: ECM++, SPring, Pico, ... Also it is enough 
that the block export the API of the components, implementation classes 
can be shielded.

> But in theory OSGI-based blocks could already be built totally outside 
> of the main build, and loaded later as bundles.

Yes, but to make it practical we would need dynamic configuration 
handling. And as the component manager per block is much better we 
shoould focus on that.

/Daniel

Mime
View raw message