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.
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.
WDYT?
/Daniel
