Gianugo Rabellino wrote:
On Wed, 16 Feb 2005 11:42:06 -0800, Ralph GoersThe problem with cocoon.xconf is that it is part of the war file. This makes it very difficult for our operations folks to change it since it will get over-ridden each time the app is redeployed. Unfortunately, they are the best ones to know just how much resources they are going to give the JVM. While we might know, the average of how many times a particular transformer is used in pipelines, they will be the ones determining just how many users they want each instance to support. This makes that an ideal value for something that should be configured outside the webapp. However, other configuration items are better left in cocoon.xconf inside the war because they shouldn't be changed. On the other hand, locating logkit.xconf inside the webapp would be most irritating if I hadn't replaced the default log manager with something else.
<[EMAIL PROTECTED]> wrote:
Carsten Ziegeler wrote:
a) Use of properties in all xconf files. If you write ${my.property} then this is replaced during loading of the xconf with the actual value of the property. - for compatibility, if there is no value for this property, the reference is left in place. There are different ways to specify properties as you will see soon, for now this is just a system property: so if you start Cocoon with -Dmy.property=something it gets replaced.
So, WDYT?
I'd love this in 2.1. This would really help with configuring pool sizes - especially if it could be done something like:
pool-max="${max_users}*10"
Which is exactly what I'm afraid of. Instead than solving the real issue (a painful configuration model), this looks like a workaround easily leading to abuses. I'm not sure that adding a fourth configuration point (web.xml, cocoon.xconf, logkit.xconf) is a good long term solution. Even more if you consider how easily property files, read from four different points, might bring unexpected results, effectively making the configuration even more opaque.
You might get a similar yet much more predictable and controlled result using off-line generation of configuration files from templates: runtime expansions smells trouble to me.
Ciao,
From my point of view, things that make sense to be modified by the operations staff belong in a properties file or an XML file external to the webapp.
Ralph
