I tend to agree with Luca on this, so I would like to add support for reading properties from WEB-INF/cocoon/properties/*.properties and WEB-INF/cocoon/spring/*.properties
again (of course with additional support of running modes). If noone is against it, I'll add it in the next days. I think this is the last remaining code change befor we can release a 1.0 version of this stuff. Carsten 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. > > Regards, > > -------------------- > Luca Morandini > www.lucamorandini.it > -------------------- > > -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
