Reinhard Poetz schrieb: > Carsten Ziegeler wrote: >> In the last months we changed the handling of properties and >> configurations files several times. >> >> The current implementation is a clean solution which reads configuration >> files from the classpath. While this is a very nice solution, especially >> for distributing components, it has the drawback that currently users >> have to put their own global configuration either into a jar file or >> into WEB-INF/classes/META-INF/cocoon. >> >> (I recently updated this mechanism to give properties from >> WEB-INF/classes precedence over jar files). >> >> 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. > > FWIW, I would even go a step further and remove > WEB-INF/classes/META-INF/cocoon > as location for Spring beans and Avalon configurations. > I forgot the mention that I'm talking about cocoon/properties/*.properties - Property settings cocoon/avalon/*.xconf - Avalon configurations cocoon/spring/*.xml - Spring bean definitions cocoon/spring/*.properties - Spring configuration override properties
Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
