Ralph Goers skrev:
Daniel Fagerstrom wrote:
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.
Oh, OK. But we also support
<component-instance name="javascript"
class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter">
<load-on-startup>resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js</load-on-startup>
<reload-scripts>${javascript.reload-scripts}</reload-scripts>
<check-time>${javascript.check-time}</check-time>
</component-instance>
Would this be replaced by
javascript.reload-scripts = true
It was just an example of a possible convention for using properties as
paths in configuration files, I haven't tried to find a complete mapping
yet.
But if we could find such a convention, it would save us the work to
rewrite hundreds of configurations. So it would probably be worthwhile.
/Daniel
