Does it help to provide the Throwable as the first argument? That's what some of the overloaded LogSF/MF methods do to avoid ambiguity, if I recall.
On Fri, Sep 16, 2011 at 10:09 AM, John Vasileff <[email protected]>wrote: > > 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] > >
