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

Reply via email to