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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
