cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT] Configuring Cocoon
Date Wed, 16 Feb 2005 21:03:18 GMT
Gianugo Rabellino wrote:

>On Wed, 16 Feb 2005 11:42:06 -0800, Ralph Goers
><Ralph.Goers@dslextreme.com> 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,
>  
>
The 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.

 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


Mime
View raw message