cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: core logging
Date Wed, 30 Mar 2005 20:36:39 GMT

Vadim Gritsenko wrote:
>> Most people will agree that the most useful information ever to appear 
>> in core.log is the bit where it writes out all request parameters, 
>> request headers and session information.
> No, I won't :-)

ok I was more talking from the user/developer perspective, rather than 
the core developer perspective. I've been using cocoon for 2 years now, 
and honestly, all i ever look at is core.log to debug the incoming 
request, access.log to assess response times or sitemap.log to see how 
cocoon resolves matcher wildcards and {1} etc.

>> Possible solutions
>> 1) Configure the cocoon component with it's own logging category eg 
>> core.cocoon or cocoon.core, keeping the cocoon-logger parameter 
>> somehow as catchall logger
> This makes sense to me, so now Cocoon object will have own sub category.

cool, thanks.

>> 2) Changing line 568 in from
>> getLogger().debug(msg.toString());
>> to
>> getLogger().info(msg.toString());
> No, this does not make sense. It's debug information, so it should stay 
> at debug level.

depends who's looking at it :) But at least there is now a means for the 
interested to easily separate it out.

It would be nice to have an easy to trace logfile where one can
follow sequentially how a request is processed, what main components are 
involved, when they are called, how they affect the response etc 
(basically the things you can find out with a debugger).
This would also make it easier for beginning cocooners to learn the core 
cocoon concepts (sitemap,matchers,gen|tran|ser|act,flow,forms) and how 
they play together.

Can something like this be implemented with clever logging targets only?


View raw message