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 : http://blah.com";
- 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
exception,
- 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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
