core logging

[Jorg Heymans <jh...@domek.be>]

Hi,

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. This data gets written there 
because the cocoon component is configured by default with a catchall 
logger named "core" in web.xml (param is called cocoon-logger).
-----(from web.xml)
This logger is used for all components described in the cocoon.xconf and 
sitemap.xmap file not having specified a logger with the logger="..." 
attribute in the component configuration file.
-----

If i now want to "filter" core.log and display only the useful bits 
described above, i need to basically define all the components that 
don't declare a logger with a logging level higher than DEBUG. In 
addition i need to define all childLoggers of the "core" logger with a 
logging level higher than DEBUG.

I find this rather tedious.

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

2) Changing line 568 in Cocoon.java from
getLogger().debug(msg.toString());
to
getLogger().info(msg.toString());


Note: I prefer solution 2)


Note2: Are the logging conventions being revised for 2.2? Is it still 
useful to keep the current separation of logfiles?
(Will there be something like per-block logging?)

Thoughts?
Jorg

Re: core logging

[Vadim Gritsenko <va...@reverycodes.com>]

Jorg Heymans wrote:
> 
> 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).

There is SimpleSitemapExecutor in 2.2 - probably that's what you want.


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

As far as I see in 2.1 messages such as:

DEBUG (2005-04-01) 12:29.15:698 [sitemap] (/) PoolThread-4/PreparableMatchNode: 
Matcher 'wildcard' matched prepared pattern '' at 
file:/C:/Work/Apache/cocoon-2.1.X/build/webapp/sitemap.xmap:525:27

all go to [sitemap] target at DEBUG level - which makes filtering hard :-)


Vadim

Re: core logging

[Jorg Heymans <jh...@domek.be>]

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

Re: core logging

[Vadim Gritsenko <va...@reverycodes.com>]

Jorg Heymans 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 :-)


> This data gets written there 
> because the cocoon component is configured by default with a catchall 
> logger named "core" in web.xml (param is called cocoon-logger).
> -----(from web.xml)
> This logger is used for all components described in the cocoon.xconf and 
> sitemap.xmap file not having specified a logger with the logger="..." 
> attribute in the component configuration file.
> -----
> 
> If i now want to "filter" core.log and display only the useful bits 
> described above, i need to basically define all the components that 
> don't declare a logger with a logging level higher than DEBUG. In 
> addition i need to define all childLoggers of the "core" logger with a 
> logging level higher than DEBUG.
> 
> I find this rather tedious.
> 
> 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.


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


> Note2: Are the logging conventions being revised for 2.2? Is it still 
> useful to keep the current separation of logfiles?

Defaults has been changed for 2.2, yes. I had synced those to 2.1 branch as well 
- so many log files in default configuration do not make sense.


> (Will there be something like per-block logging?)

If you want - you can always do this. In your own configuration.

Vadim