cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Configuration handling in 2.2 (properties etc.)
Date Fri, 29 Dec 2006 14:27:34 GMT
Luca Morandini wrote:
> Reinhard Poetz wrote:
>> Carsten Ziegeler wrote:
>>> Some raised the concern on this list that this is not very intuitiv and
>>> they would like to include WEB-INF/cocoon/* to be read by default as 
>>> well.
>>> Adding support for this is very easy, it's just one more line of code,
>>> so this is not the deal. The question is if we want to provide this
>>> extra location or not?
>> I'm in the not camp. Starting with 2.2 there shouldn't be any Cocoon 
>> applications anymore that are not developed as blocks. The only 
>> exception from this rule of decentralization is Spring properties in 
>> WEB-INF/cocoon/spring as there should be a way to set them globally.
> Let me simulate a scenario: suppose I have a generators block out of 
> Cocoon distro, with some default configuration (size of pools, etc.), 
> now suppose I want those properties to change for my application: I 
> presume I have to set those properties in my application's JAR 
> (provided, of course, it is deployed as a block), right ?
> And what if my application's JAR is read before the generators block JAR 
> (as it may well happen, since they're in alphabetic order) ?
> Hence the need for a separate properties file, a file of last resort to 
> set application-wide properties, possibly properties used by many blocks.
> But, come to think of it, a sysadmin may want to tailor pools size 
> according to each server my application runs on, hence system-wide 
> properties may come in handy.
> If such system-wide properties are under classes/META-INF/... they are 
> subject to the same alphabetic order rules of JARs' properties, and this 
> could, just possibly, lead to some anomalies if other blocks are added 
> afterwards.
> Therefore, I think using WEB-INF/cocoon to store system-wide properties, 
> properties assured to be read after *all* the properties in 
> classes/META-INF/..., may still make sense.
> So, according to this line of thought, the loading order would be:
> 1) Properties in JARs (blocks, actually) to be read from 
> classes/META-INF/...
> 2) Properties *not* in JARs to be read from classes/META-INF/... and to 
> overwrite the ones in JARs (as Carsten just did).
> 3) Properties in WEB-INF/cocoon to overwrite the ones in 1 an 2.

I wasn't questioning WEB-INF/cocoon/properties/*.properties and 
WEB-INF/cocoon/spring/*.properties. For the reasons you describe above they are 

I just don't see a need for WEB-INF/cocoon/avalon/*.xconf and 

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message