fingthinking opened a new issue, #4403:
URL: https://github.com/apache/logging-log4j2/issues/4403
## Title
`log4j-slf4j-impl`: LocationAwareLogger.log() bypasses configured
MessageFactory
## Type
Bug Report / Enhancement
## Description
When using SLF4J 1.7.x with `log4j-slf4j-impl`, a custom SLF4J logging
wrapper may need to use `LocationAwareLogger.log()` to provide the fully
qualified class name (FQCN) of the wrapper, allowing Log4j2 to correctly
identify the caller location.
However, the `LocationAwareLogger.log()` implementation in `Log4jLogger`
appears to construct messages directly (e.g., using `SimpleMessage` or
`ParameterizedMessage`) rather than using the `MessageFactory` configured for
the underlying Log4j2 logger.
As a result, the configured `MessageFactory` or `MessageFactory2` is
bypassed when logging through this API.
This creates a problem for applications that need both:
- Correct caller location information when logging through a wrapper.
- Consistent message construction semantics provided by a custom
`MessageFactory` or `MessageFactory2`.
Using the regular SLF4J methods, such as `Logger.info()`, preserves the
normal message construction path but does not allow the wrapper to explicitly
provide its FQCN. Using `LocationAwareLogger.log()` allows the FQCN to be
specified but appears to bypass the configured message factory.
## Steps to Reproduce
1. Configure a custom Log4j2 `MessageFactory` that produces a
distinguishable custom `Message` implementation.
2. Obtain an SLF4J logger backed by `log4j-slf4j-impl`.
3. Cast the logger to `LocationAwareLogger`.
4. Invoke `LocationAwareLogger.log()` with a message and arguments.
5. Observe whether the configured `MessageFactory` is invoked.
For example:
```java
LocationAwareLogger logger =
(LocationAwareLogger) LoggerFactory.getLogger("example");
logger.log(
null,
WrapperLogger.class.getName(),
LocationAwareLogger.INFO_INT,
"value={}",
new Object[] { 42 },
null
);
```
Compare this behavior with a regular SLF4J call:
```java
LoggerFactory.getLogger("example").info("value={}", 42);
```
## Expected Behavior
The `LocationAwareLogger.log()` path should preserve the configured
`MessageFactory` / `MessageFactory2` semantics while honoring the supplied FQCN
for caller location calculation.
Alternatively, the implementation or documentation should clearly specify
that `LocationAwareLogger.log()` intentionally bypasses the configured message
factory and explain the recommended approach for wrappers that require both
custom message construction and accurate caller location information.
## Actual Behavior
The `LocationAwareLogger.log()` implementation constructs the message
through its own code path rather than delegating message construction to the
configured `MessageFactory` / `MessageFactory2`.
Consequently, custom message factories may not be invoked, and applications
relying on custom message construction observe different behavior depending on
whether they use regular SLF4J logging methods or `LocationAwareLogger.log()`.
## Environment
- SLF4J API: 1.7.x
- Log4j2: 2.23.1
- Binding: `log4j-slf4j-impl`
## Use Case
A logging wrapper delegates to an SLF4J `Logger`. The wrapper needs to
supply its FQCN so that Log4j2 can skip the wrapper when calculating caller
location. At the same time, the application relies on a custom `MessageFactory`
/ `MessageFactory2` for message construction.
Currently, neither the regular SLF4J methods nor `LocationAwareLogger.log()`
appears to satisfy both requirements.
Would it be possible to preserve the configured message factory behavior in
the `LocationAwareLogger.log()` implementation, or provide a supported
mechanism for specifying the caller boundary without bypassing normal message
construction?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
