+1 for lowering the log level to WARN. But it'd be much better to provide two (or more) typical configurations, e.g.: - development: log level - DEBUG, development cache settings, etc. - testing: log level - WARN, etc. - production: log level - ERROR, etc.
What do you think?
This could be done now with the new custom-config build target I've been working on which uses <xpatch>. Currently, the only way to do this would be to provide multiple patch files for the log xconf which rely on different build properties (like config.loglevel.warn=true) because no variable expansion is done on the contents of the xpatch.
(see:
http://wiki.cocoondev.org/Wiki.jsp?page=XPatchTaskUsage
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject (my comment at the end)
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=105440069221225&w=2
It would be nice to enable variable substitution though. I looked at the ant docs but 1) saw a warning of API instability in the package/class that looked like what I'd need to do the expansion 2) only saw methods to operate on strings, but didn't see a clean way to do so for xml being parsed in.
Any takers to help me out?
Geoff
