You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/09/11 15:35:15 UTC
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
cziegeler@apache.org wrote:
>cziegeler 2002/09/11 03:08:36
>
>
<snip/>
> Index: ActionSetNodeBuilder.java
> ===================================================================
> RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- ActionSetNodeBuilder.java 24 Jun 2002 20:32:19 -0000 1.3
> +++ ActionSetNodeBuilder.java 11 Sep 2002 10:08:33 -0000 1.4
> @@ -101,7 +101,6 @@
> } else {
> // Unknown element
> String msg = "Unknown element " + name + " in action-set at " + childConfig.getLocation();
> - getLogger().error(msg);
> throw new ConfigurationException(msg);
> }
> }
>
>
<snip/>
I'm a little bit disappointed by this update. Because of lack of time, I
didn't participate to the "Make errors caught only by Cocoon.java"
discussion, and I agree that _exceptions_ should be logged only once.
Now the above change removes the log of a _message_ and not that of an
_exception_. I explained in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100884840411961&w=2 why
I think logging a message when an exception is _thrown_ (and not
catched) is good :
- the message is logged into the component's category,
- the context may contain additional information placed there by the
callers.
Also, I don't consider this as over-logging :
- a _message_ is logged when the error condition is encountered (and the
exception thrown)
- the _exception_ is logged when some high-level class (here Cocoon)
catches the exception and cannot take a corrective action when receiving
that exception.
Thoughts ?
Sylvain
(of course, I volunteer for undoing the change if we agree on that...)
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote
>
>
>>Ahem... according to the second item, don't remove message logs before
>>throwing an exception, but change them to warn.
>>
>>
>>
>Hey, don't worry - this was just a joke :)
>
>
Pheeeeew... you make me nervous, Carsten ;-)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote
>
> Ahem... according to the second item, don't remove message logs before
> throwing an exception, but change them to warn.
>
Hey, don't worry - this was just a joke :)
Bye
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>
>>Actually, this is something I was considering by looking at the priority
>>filter in logkit.xconf that directs all errors regardless their category
>>to the error log file. I also considered redirecting only "core" errors
>>to that file.
>>
>>Referring to the definition of priorities (see
>>http://jakarta.apache.org/avalon/logkit/whitepaper.html), we see that a
>>warning is "A problem or conflict has occurred but it may be
>>recoverable, then again it could be the start of the system failing".
>>
>>So we can consider that a low-level component that fails should issue
>>warnings instead of errors since it doesn't know if the error can be
>>recovered by a higher-level component. This also shows that the logging
>>priority is a relative concept that depends on the responsibility of a
>>component in the system.
>>
>>So ok for warn !
>>
>>So as a summary :
>>- Logging _errors_ is reserved to high-level entities such as Cocoon and
>>CocoonServlet,
>>- A component that fails _can_ log a _warning_ before throwing an
>>exception,
>>- An exception that is catched and propagated _must not_ be logged, even
>>if wrapped in a CascadingException.
>>
>>Do we agree on this ?
>>
>>
>>
>
>Absolutely! - So, I can keep on removing things... :-)
>
Ahem... according to the second item, don't remove message logs before
throwing an exception, but change them to warn.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Actually, this is something I was considering by looking at the priority
> filter in logkit.xconf that directs all errors regardless their category
> to the error log file. I also considered redirecting only "core" errors
> to that file.
>
> Referring to the definition of priorities (see
> http://jakarta.apache.org/avalon/logkit/whitepaper.html), we see that a
> warning is "A problem or conflict has occurred but it may be
> recoverable, then again it could be the start of the system failing".
>
> So we can consider that a low-level component that fails should issue
> warnings instead of errors since it doesn't know if the error can be
> recovered by a higher-level component. This also shows that the logging
> priority is a relative concept that depends on the responsibility of a
> component in the system.
>
> So ok for warn !
>
> So as a summary :
> - Logging _errors_ is reserved to high-level entities such as Cocoon and
> CocoonServlet,
> - A component that fails _can_ log a _warning_ before throwing an
> exception,
> - An exception that is catched and propagated _must not_ be logged, even
> if wrapped in a CascadingException.
>
> Do we agree on this ?
>
Absolutely! - So, I can keep on removing things... :-)
Regards
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>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?
>
>
Actually, this is something I was considering by looking at the priority
filter in logkit.xconf that directs all errors regardless their category
to the error log file. I also considered redirecting only "core" errors
to that file.
Referring to the definition of priorities (see
http://jakarta.apache.org/avalon/logkit/whitepaper.html), we see that a
warning is "A problem or conflict has occurred but it may be
recoverable, then again it could be the start of the system failing".
So we can consider that a low-level component that fails should issue
warnings instead of errors since it doesn't know if the error can be
recovered by a higher-level component. This also shows that the logging
priority is a relative concept that depends on the responsibility of a
component in the system.
So ok for warn !
So as a summary :
- Logging _errors_ is reserved to high-level entities such as Cocoon and
CocoonServlet,
- A component that fails _can_ log a _warning_ before throwing an exception,
- An exception that is catched and propagated _must not_ be logged, even
if wrapped in a CascadingException.
Do we agree on this ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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.
This works of course only if the exception is logged somewhere -
this musg be guaranteed.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Sylvain Wallez wrote:
>
>> cziegeler@apache.org wrote:
>>
>>> cziegeler 2002/09/11 03:08:36
>>>
>>>
>> <snip/>
>>
>>> Index: ActionSetNodeBuilder.java
>>> ===================================================================
>>> RCS file:
>>> /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java,v
>>>
>>> retrieving revision 1.3
>>> retrieving revision 1.4
>>> diff -u -r1.3 -r1.4
>>> --- ActionSetNodeBuilder.java 24 Jun 2002 20:32:19 -0000 1.3
>>> +++ ActionSetNodeBuilder.java 11 Sep 2002 10:08:33 -0000 1.4
>>> @@ -101,7 +101,6 @@
>>> } else {
>>> // Unknown element
>>> String msg = "Unknown element " + name + " in
>>> action-set at " + childConfig.getLocation();
>>> - getLogger().error(msg);
>>> throw new ConfigurationException(msg);
>>> }
>>> }
>>>
>>>
>>
>> <snip/>
>>
>> I'm a little bit disappointed by this update. Because of lack of
>> time, I didn't participate to the "Make errors caught only by
>> Cocoon.java" discussion, and I agree that _exceptions_ should be
>> logged only once.
>>
>> Now the above change removes the log of a _message_ and not that of
>> an _exception_. I explained in
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100884840411961&w=2
>> why I think logging a message when an exception is _thrown_ (and not
>> catched) is good :
>> - the message is logged into the component's category,
>> - the context may contain additional information placed there by the
>> callers.
>>
>> Also, I don't consider this as over-logging :
>> - a _message_ is logged when the error condition is encountered (and
>> the exception thrown)
>> - the _exception_ is logged when some high-level class (here Cocoon)
>> catches the exception and cannot take a corrective action when
>> receiving that exception.
>>
>> Thoughts ?
>
>
> I strongly think that errors should not be caught where originating,
> even if only for logging.
Ahem... does the above have sense ? How can you catch an exception where
you originate it ? ;-)
> Exceptions must be caught *only* when handled.
That's exactly what I say in the mentioned post.
> Logging it is *not* handling it.
> This is how exceptions must be done in Java throughout, not only a
> Cocoon thing.
>
> BUT
>
> 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 ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> cziegeler@apache.org wrote:
>
>> cziegeler 2002/09/11 03:08:36
>>
>>
> <snip/>
>
>> Index: ActionSetNodeBuilder.java
>> ===================================================================
>> RCS file:
>> /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java,v
>>
>> retrieving revision 1.3
>> retrieving revision 1.4
>> diff -u -r1.3 -r1.4
>> --- ActionSetNodeBuilder.java 24 Jun 2002 20:32:19 -0000 1.3
>> +++ ActionSetNodeBuilder.java 11 Sep 2002 10:08:33 -0000 1.4
>> @@ -101,7 +101,6 @@
>> } else {
>> // Unknown element
>> String msg = "Unknown element " + name + " in
>> action-set at " + childConfig.getLocation();
>> - getLogger().error(msg);
>> throw new ConfigurationException(msg);
>> }
>> }
>>
>>
>
> <snip/>
>
> I'm a little bit disappointed by this update. Because of lack of time, I
> didn't participate to the "Make errors caught only by Cocoon.java"
> discussion, and I agree that _exceptions_ should be logged only once.
>
> Now the above change removes the log of a _message_ and not that of an
> _exception_. I explained in
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100884840411961&w=2 why
> I think logging a message when an exception is _thrown_ (and not
> catched) is good :
> - the message is logged into the component's category,
> - the context may contain additional information placed there by the
> callers.
>
> Also, I don't consider this as over-logging :
> - a _message_ is logged when the error condition is encountered (and the
> exception thrown)
> - the _exception_ is logged when some high-level class (here Cocoon)
> catches the exception and cannot take a corrective action when receiving
> that exception.
>
> Thoughts ?
I strongly think that errors should not be caught where originating,
even if only for logging.
Exceptions must be caught *only* when handled.
Logging it is *not* handling it.
This is how exceptions must be done in Java throughout, not only a
Cocoon thing.
BUT
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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org