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.
Ralph
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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
