cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [2.2] Configuration issues
Date Wed, 17 May 2006 21:26:59 GMT
Ralph Goers skrev:
> 
> 
> 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 
>> http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html.

>>
>>
>> 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.

No, I meant something different than the mechanism today, something that 
works like the PropertyOverrideConfigurer in Spring. Say that you have a 
configuration file like:

   <store logger="core.store">
     <parameter name="maxobjects" value="1000"/>
     <parameter name="use-cache-directory" value="true"/>
   </store>

Then my idea was that you should be able to override the maxobjects 
property by just providing a property:

store.maxobjects=2000

The mechanism of today is more like the PropertyPlaceholderConfigurer in 
Spring and would require you to rewrite the configuration file like:

   <store logger="core.store">
     <parameter name="maxobjects" value="${store.maxobjects}"/>
     <parameter name="use-cache-directory" 
value="${store.use-cache-directory}"/>
   </store>

and provide default property files for all properties.

/Daniel


Mime
View raw message