logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: log4j2 parameterized msg with throwable
Date Thu, 15 Sep 2011 23:46:52 GMT
My gut reaction is that I agree with you. I ran across this behavior a while ago and Joern
mentioned that ParameterizedMessage was working the way it is supposed to, which given the
behavior you are noting just doesn't seem correct.

On the other hand, currently not every Message implementation cares about Throwables.  I'm
not sure what StructuredDataMessage should do with one, for example.  What do you think should
be done to handle that?

I realized the other day in an email exchange with Joern that I had neglected to support the
ExtendedThrowablePatternConverter and have been working on that.  Once I complete that I'll
be happy to work on this. If you have ideas feel free to submit Jira patches. If you don't
have an ICLA on file I would suggest you do that.  I would love to have your help in taking
this forward.


On Sep 15, 2011, at 9:32 AM, John Vasileff wrote:

> Should logs that use ParameterizedMessage support trailing throwables? The ParameterizedMessage
code identifies throwables in the argument array, but they are silently ignored.  This is
for methods like:
> void info(String message, Object... params);
> Example:
> log4j2Logger.info("log4j2Logger no params with throwable?", t); // works
> log4j2Logger.info("log4j2Logger {}", "params with throwable?", t); // fails
> Output:
> 2011-09-15 11:55:40,497 INFO Log4j2Testing [main] log4j2Logger no params with throwable?
> java.lang.Throwable
> 	at Log4j2Testing.main(Log4j2Testing.java:18)
> 2011-09-15 11:55:40,499 INFO Log4j2Testing [main] log4j2Logger params with throwable?
> On a related note, consider Logger methods like the following:
> void info(Message msg);
> void info(Message msg, Throwable t);
> If Message objects support Throwables, as may be true for ParameterizedMessage or future
message types (end user created or new to be conceived log4j2 standard messages), there is
ambiguity in the second method as to which throwable is "the" throwable.  Perhaps the first
non-null, or maybe the explicit argument overrides the msg throwable.  In any case, it is
a bit confusing.
> Perhaps the second method with an explicit Throwable should be eliminated, and Message
objects should support Throwables when desired.  getThrowable() could be added to the Message
interface, or even a separate MessageWithThrowable interface similar to the way FormattedMessage
works.  (The former may be better to avoid having too many interfaces and instanceof clutter.)
> It seems to me that throwables are a natural part of messages, just as the formatted
message strings and parameters are.
> It doesn't look like adding throwables to Messages would cause additional overhead. 
In cases like ParameterizedMessage, it standardizes the approach to throwables and gives the
Message object more power.  In other cases, it just changes the location of a parenthesis
in the code:
> public void info(String message, Throwable t) {
>    if (isEnabled(Level.INFO, null, message, t)) {
>        log(null, getFQCN(), Level.INFO, new SimpleMessage(message), t);
>    }
> }
> becomes:
> ...
>        log(null, getFQCN(), Level.INFO, new SimpleMessage(message, t));
> ...
> John
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message