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