cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [2.2] Configuration issues
Date Wed, 17 May 2006 13:40:02 GMT

Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> I'm currently wondering what the best way to configure 2.2 from a user
>> perspective is. We now have includes for xconfs and property
>> replacements which is great.
>> Now, each block comes with its own configuration files: all of them are
>> stored in the jar and on deployment some of these files are extracted:
>> so in the end there are roles files in the jar, xconf and property files
>> on the WEB-INF folder.
>> A user should never touch/change these files - so only way to customize
>> the settings is through properties. This requires that each and every
>> user configurable value must be replaced with a property! Now while this
>> approach is fine it has at least two problems:
>> 1. A huge number of properties which sooner or later will create a mess.
> Requiring the user of the block to define every property is far to 
> inconvenient and error prone. A much better model is to have default 
> values in the configuration file in the block and make it possible for 
> the block user to optionally override the default value with own 
> properties. This is the way configuration is handled in OSGi with a 
> declarative service configuration file that gives the default and a 
> configuration service that can override the default. Spring has some 
> similar mechanism with the PropertyOverrideConfigurer 

> For the Avalon configurations we could find some convention for 
> translating configuration file element paths to property strings and 
> then write a implementation of the avalon Configuration that override 
> the configuration file based configuration with the property values. 
> And feed that overridable configuration to the component in the 
> BeanPostProcessor for the Avalon life cycle.
This is already the way it works in both 2.1 and 2.2.  Cocoon provides 
values for everything in property files within the block. The user can 
then provide their own values which override them. I think Carsten is 
simply worried because there are a lot of values you can specify.
>> 2. This works only as long as the user wants to use the same
>> implementation for a component. Switching to an own implementation with
>> an own configuration is not possible.
>> Any idea on how to solve this?
> Here the IMO best and most natural solution is to have different 
> blocks for different implementations. Say we have two different 
> components that implements the XsltProcessor inteface, the Xalan and 
> the Saxon implementation. Then if you have a Xalan block with its own 
> embedded configuration and a Saxon block with its own embedded 
> configuration. If you want to use the Xalan implementation you deploy 
> the Xalan block and if you want the Saxon implementation you deply the 
> Saxon block.
> The result of this thinking is that you have typically smaller and 
> more focused blocks, that contain components that are used togerther.
I think Carsten is worried about the Portal. The portal has a lot of 
configurable elements in it.
> /Daniel

View raw message