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
