cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Configuration issues
Date Wed, 17 May 2006 20:58:03 GMT
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 


View raw message