Ok, very interesting approach - ok, I agree that this is a way or working which requires to choose different loggers for different components (or types) etc. We simply look in the error log and don't care about other logs or categories. And in this error log the message and the exception is logged.
Ok, how can we get a consense here? I would agree with you, if you look the message not with the level "error" but with level "warn". :) What do you think about this? Carsten Sylvain Wallez wrote: > > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
