cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon
Date Thu, 12 Sep 2002 08:24:21 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>>In the above case, it is starting to throw something, so it's ok, and 
>>>even good, that something is logged.
>>>It's not the exception being logged, but the event that will cause the 
>>>exception to be thrown. 
>>That's exactly what I mean.
>>Carsten, what do you think ?
>Sorry, but I don't agree here. There is a reason for the thrown exception
>and the common handling of this is to put this reason into the message
>of the exception.
>When this exception is logged you see the reason/message/event that
>caused the exception.
>If you do log the event apart from the exception, then you will again
>get two entries: one with the sole event and one with the exception
>which is then the same text. And that's disturbing.
>We tought many new cocooners over the last months and they always very
>absolutely confused and actually got lost by the mass of messages
>appearing in the log when one single exception is thrown, because
>that single event is/was logged several times. So I still think,
>logging once is enough.

Cocoon (through Avalon) has nice features to cleanly categorize the 
logs. If a component doesn't log a message in *its own category* when it 
detects an error condition and raises an exception, then the usefullness 
of a cleanly crafted category hierarchy is near zero : the component's 
message is logged somewhere else in the category hierarchy and may be 
difficult to correlate it with the actual component instance that has 
the problem.

Let's take an example. AbstractTextSerializer is the base class for many 
serializers : TextSerializer, XMLSerializer, HTMLSerializer. Even 
consider XMLSerializer, which has several instances in a typical sitemap 
(XML, SVG, WML), each having its own logging category. Now suppose a 
problem is detected in AbstractTextSerializer that leads to throwing an 
exception. Where will the message be logged ? With your proposal, it 
will be in "core" (associated to Cocoon). And it will be "core" for 
*all* serializers based on AbstractTextSerializer, and the stacktrace is 
likely to mention only AbstractTextSerializer, and not the actual subclass.

So, how can we know which serializer is actually having a problem ? The 
answer is : we can't !!

                                 -- o --

If a _message_ is logged by AbstractTextSerializer, that message will go 
either in category "sitemap.serializer.xml" or "sitemap.serializer.svg" 
depending on the actual component instance, and finding the offending 
component is then really easy.

Cocoon will then log the _exception_ in its own "core" category, because 
it decides to take a corrective action (display and error screen) and 
not to propagate the exception.

Note also that the text associated with the two log entries should be 
different as they are of different abstraction levels :
- the serializer issues e.g. a "Undeclared namespace :"
- Cocoon issues a "Cannot handle request 'mypage.xml' - displaying error 
page" followed by the cause, which is the exception containing the 
serializer message.

                                 -- o --

Side note : we use here LF5 to manage logs. This is a Swing GUI that 
displays the category tree and allows filtering of a given category 
through a few mouse clicks. When tracking a problem on a given 
component, we display *only* the logs of the category associated to this 
component. This makes finding problems a breeze if (and only if) logs 
are correctly categorized.

LF5 was originally a commercial product from Servidium, potentially 
accepting any logging system but shipped only with log4j integration. We 
wrote the bridge for logKit in order to use it with Cocoon. LF5 was 
recently donated to log4j after Servidium was bought by another company. 
If people are interested in it (and I guess they will), I can donate 
this logKit bridge.

                                 -- o --

To conclude this long post, I agree that current logging in Cocoon is 
way too verbose and that people (and even developpers) easily get lost. 
But this is mainly because a thrown exception is logged at many places 
when it crawls up the call stack.

So my proposal is to :
- log a *message* in the *appropriate category* prior to throwing an 
- log an *exception* with some high level message when it is catched and 
*not propagated* (throwing a wrapper *is* propagating).

Practically, this effectively means a problem can be reported twice (and 
not more) in the logs : a message in the component's category, and an 
exception in the category associated to a high-level entity that decides 
not to propagate the exception. But once again, the messages should be 
slightly different.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message