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
