On Sep 15, 2011, at 7:46 PM, Ralph Goers wrote:
> 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 think it is analogous to getParameters(). It is a common feature, but not
one that all Message types need. So I think the question is how granular the
interfaces should be. Message could have _only_ getFormattedMessage(), and
everything else added by sub interfaces. But for very common things like
Throwables or Parameters, I tend to think it is easier to have them in the main
Message interface and avoid instanceof clutter in the rest of the code.
SimpleMessage has:
/**
* Returns null since there are no parameters.
* @return null.
*/
public Object[] getParameters() {
return null;
}
So StructuredDataMessage can have:
/**
* @return null; StrucutredDataMessages never have Throwables.
*/
public Throwable getThrowable() {
return null;
}
> 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.
>
A patch for this is on the way.
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
