This sounds like it might be a good basis for figuring out a parallel v3 API
for a “hard to mis-use” style API. However, once you go that route, you start
to wonder how useful templated log messages are when you can capture a lambda
instead. Parameterized log messages might work better as structured log
messages, something that is awkward to use in the API at the moment.
—
Matt Sicker
> On Nov 21, 2023, at 08:16, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
>
> 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
