Carsten Ziegeler skrev:
Reinhard Poetz wrote:
How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency
injection but considering interface/implementation relations. You can use the
OSGi configuratonAdmin service to change an injected component or a component's
properties.
Ok, but this is then configuration at runtime and not at development
time, right?
The configuration admin is called when a service (component) is registered.
Where are those values stored?
According to the spec they are stored persistently. The actual storage
mechanism is not standardized though. In Felix they talking about
connecting the configuration admin to the storage API from the directory
project so that configurations can be stored in e.g. an LDAP server.
Reinhard and I have discussed initializing the configuration admin from
an XML or property file.
Additionally we have the possibility to redisgn e.g. forms and portal to use the
OSGi whiteboard pattern[1]. Using it makes extending them very simple as it
makes extensions very simple - you just have to provide a component that
implements a particular interface and it is automatically added as reference to
another component.
I don't want to rewrite blocks in order to use OSGi and I think one of
our main goals for using OSGi is that this does not affect the way how I
develop blocks which means it is totally transparent. So imho we need an
OSGi-free way which works at development time.
The whiteboard pattern isn't about OSGi per se, but rather about how to
organize extensible components in a plugin based architecture. The
configuration model that is used for CForms is not suitable for a plugin
architecture at all, as it assumes a single complete list of all
components in one place. If you want to ad a component you need to edit
the central configuration file.
With the whiteboard pattern, each plugin register its services, e.g.
validators and widgets, in a registry (the whiteboard). Then the user,
e.g. the form framework search for the services it needs from the
registry. This is much more flexible and extensible than the current
architecture.
/Daniel
