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 Cocoon.java 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?
Jorg
