You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <co...@leverageweb.com> on 2003/06/04 14:04:34 UTC

Re: Log level, compatibility (was: Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace)

At 02:14 AM 6/4/2003, Konstantin wrote:

>+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 


RE: Log level, compatibility

Posted by Geoff Howard <co...@leverageweb.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]

> Geoff Howard wrote:
>
> > At 02:14 AM 6/4/2003, Konstantin wrote:
> >
> >> +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.
> >
>
> INFO should be even better.
>
> ...
>
> > Any takers to help me out?
>
>
> Why not simply error.level in build.properties and ant filtering of
> logkit.xconf? Simple, and no additional code.
>
> Vadim

That would work for this case but the build is not currently filtering
logkit.xconf is it?  In general people have asked for this ability, and
I'd find it useful.  Doesn't need to be tied to any log level change though,
just fishing. ;)

As an update, I tried using org.apache.tools.ant.filters.ExpandProperties
which extends java.io.Reader to wrap the File object on the way in to the
DocumentBuilder, but was getting errors.

Geoff


Re: Log level, compatibility

Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:

> At 02:14 AM 6/4/2003, Konstantin wrote:
>
>> +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. 
>

INFO should be even better.


>>   - production: log level - ERROR, etc.
>>
>> What do you think?
>
...

> Any takers to help me out? 


Why not simply error.level in build.properties and ant filtering of 
logkit.xconf? Simple, and no additional code.

Vadim