You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2005/04/12 18:50:02 UTC
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
sylvain@apache.org wrote:
>
> } catch (ProcessingException e) {
> + // Log the original exception
> + getLogger().error("Failed to process error handler for exception", e);
> throw e;
I think we had an agreement against mile-long log files. Why log exception here
if it will be logged later on (by the caller)?
> } catch (Exception e) {
> throw new ProcessingException("Failed to handle exception <" + ex + ">", e);
> }
(note: here it is logged at all)
Vadim
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> So, what about:
> - remove the printStackTrace() methods that also print the stacktrace of
> nested exceptions
Cocoon 2.1.x series support jdk 1.3, so I don't think we should do it... Going
forward though, in 2.2.x, we could remove that.
> - add a new %{rootThrowable} for the CocoonLogFormatter that prints the
> root exception, as given by NotifyingBuilder.getRootCause.
Nice idea. Done.
Vadim
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> While we're talnking about exceptions, what about NOT logging a
> stacktrace whenever no sitemap match is found? With the current
> behavior, we get a stacktrace, for example, everytime a browser requests
> "/favicon.ico", which happens quite frequently. Can't we just log a
> one-line message?
+1000000
--
Stefano.
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> While we're talnking about exceptions, what about NOT logging a
> stacktrace whenever no sitemap match is found? With the current
> behavior, we get a stacktrace, for example, everytime a browser
> requests "/favicon.ico", which happens quite frequently. Can't we just
> log a one-line message?
+1. IIRC Stefano alreay raised this issue.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Jorg Heymans <jh...@domek.be>.
Amen, i have been known to put a matcher in my sitemaps for this, just
to get rid of it. A one-liner suffices.
I had a quick glance at the code in PipelineNode.java where this
exception is thrown but i'm not sure at which level the code can be
modified without disturbing the flow of events.
I suspect that there must be a way of removing the stacktrace logging
without touching the exception throwing but i don't see it, can anyone
enlighten me ?
Jorg
Ugo Cei wrote:
> While we're talnking about exceptions, what about NOT logging a
> stacktrace whenever no sitemap match is found? With the current
> behavior, we get a stacktrace, for example, everytime a browser requests
> "/favicon.ico", which happens quite frequently. Can't we just log a
> one-line message?
>
> Ugo
>
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Ugo Cei <ug...@apache.org>.
While we're talnking about exceptions, what about NOT logging a
stacktrace whenever no sitemap match is found? With the current
behavior, we get a stacktrace, for example, everytime a browser
requests "/favicon.ico", which happens quite frequently. Can't we just
log a one-line message?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: svn commit: r161067 - cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> sylvain@apache.org wrote:
>
>>
>> } catch (ProcessingException e) {
>> + // Log the original exception
>> + getLogger().error("Failed to process error handler
>> for exception", e);
>> throw e;
>
>
> I think we had an agreement against mile-long log files. Why log
> exception here if it will be logged later on (by the caller)?
Oops, sorry. I wanted to log "ex", the original exception, that got lost
if there was an exception in the error handler.
>> } catch (Exception e) {
>> throw new ProcessingException("Failed to handle
>> exception <" + ex + ">", e);
>> }
>
>
> (note: here it is logged at all)
Yep. But here again we loose the original exception's stacktrace.
BTW, talking about mile-long logs: we hava a number of exception classes
that log themselves and their chainged exception if present. And there
are also some exceptions (like SAXException) that can be chained but
don't log their cause. Add to this JDK 1.4's printStackTrace that also
prints the stacktrace of nested exceptions.
The result is that we currently can have some exceptions being dumped
multiple times because they are dumped by their parent and also by the
JDK 1.4, and other exceptions whose cause is not printed in the logs at
all because they're shielded by their wrapping exception.
So, what about:
- remove the printStackTrace() methods that also print the stacktrace of
nested exceptions
- add a new %{rootThrowable} for the CocoonLogFormatter that prints the
root exception, as given by NotifyingBuilder.getRootCause.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director