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: Configuration handling in 2.2 (properties etc.)
Date Fri, 29 Dec 2006 10:45:39 GMT
 From my narrow perspective I don't really think it is necessary.  
However, I just went and looked at some of the configurations and 
noticed that one of the enhancements I made to 2.1 is not reflected in 
trunk.  I thought I had made the corresponding changes there but maybe I 
didn't since at the time I had no way of testing anything. 

I changed all the items that would likely need to be tunable to be 
parameterized.  For example, the pool size for most generators is 
hard-coded at 16.  This is a PITA to modify when it is coming from 
Cocoon core.  These values should all be parameterized like they are in 
2.1.  I see that the store sizes have been set up to do this, but 
everything in 2.1's  src/webapp/WEB-INF/properties/core.properties needs 
to also be reflected in trunk, unless they no longer apply.

Speaking of pooling, (well, we weren't really, but I don't want to start 
another email) I thought we were going to replace the pooled generators, 
etc. with a factory.  What ever happened with that? I thought there was 
a FileGenerator version of that but I don't see it now.

Ralph

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?
>
> WDYT
> Carsten
>
>   

Mime
View raw message