Hi,
Profiting from release 3.x we could slightly change the interpretation
of throwable parameters used in logging methods.
IIRC in one of our online meetings, we raised the issue of logging
statements like this:
logger.info("Error nr {}: {}", nr, throwable);
which is not considered best practice and is probably not what the
user intended:
logger.info("Error nr {}: {}", nr, throwable.getMessage(), throwable);
A similar problem was reported in PR #1050[2].
Regarding this kind of statements, the OSGi Log[1] Service provides a
very nice alternative interpretation on how to deal with throwable
parameters:
"If the last argument is a Throwable or a ServiceReference, it is
added to the generated LogEntry and then, if the next to last argument
is a ServiceReference or Throwable and not the same type as the last
argument, it is also added to the generated LogEntry. These arguments
will not be used as message arguments."
Should we adopt a similar interpretation in 3.x? The advantages I see are:
1. We fix some inconsistencies in the API:
* we have a pair `info(String, Throwable)/info(String, Object)`
methods that prevents users from mistakenly pass a `Throwable` as a
log message argument,
* we only have `info(Object)`,
* we only have `info(String, Object, Object)`.
2. We simplify our logic: right now we need logic to deal with
throwables in `Message`. On the other hand throwables are not
considered part of a message by any layout and are also included
separately in LogEvent. If we don't need to chase throwables in
parameterized messages, we don't need to parse the format string until
it is required.
3. There might be some cases when including throwables in a log
message leads to information disclosure (e.g. when a user sees a log
message, but not the attached throwable). This way we'll have an API
which is easy to use and hard to misuse.
Piotr
[1]
https://docs.osgi.org/javadoc/osgi.core/8.0.0/org/osgi/service/log/Logger.html
[2] https://github.com/apache/logging-log4j2/pull/1050
