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
[EMAIL PROTECTED] 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
Vadim Gritsenko wrote:
[EMAIL PROTECTED] 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
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 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
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
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
