[
https://issues.apache.org/jira/browse/LOG4J2-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503880#comment-17503880
]
Ceki Gulcu commented on LOG4J2-2975:
------------------------------------
SLF4J version 1.8 has been superseded by version 2.0. Moreover, SLF4J 1.8 does
not include a fluent API.
There is a {{org.slf4j.spi.DefaultLoggingEventBuilder.setCallerBoundary()}}
method which allow you to set the correct caller boundary, for example the
class name of your wrapper.
As of 2.0.0-alpha7, the {{log}} methods in {{DefaultLoggingEventBuilder}}
invoke {{setCallerBoundary}} with the value
{{DefaultLoggingEventBuilder.class.getName()}}.
See also https://github.com/qos-ch/slf4j/commit/6df6053c24fe
> SLF4J fluent API fails to capture call site location due to missing
> LoggingEventAware implementation
> ----------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-2975
> URL: https://issues.apache.org/jira/browse/LOG4J2-2975
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
> Affects Versions: 2.13.3
> Reporter: Daniel Gray
> Assignee: Ralph Goers
> Priority: Major
>
> The logger outputs the wrong log line (120 for INFO, 117 for DEBUG, etc.)
> instead of the line in the program that generated the log, when running with
> the slf4j bridge. *This causes potential confusion when a person debugging
> something is reading the logs as the line numbers are wrong!*
> I have prepared 2 simple CLI apps to show the correct behavior (with only
> Log4J) and the incorrect behavior (with the SLF4J bridge). Both are using the
> exact same configuration (log4j2.properties). The repositories of these
> sample projects are:
> Good behavior with a pure log4j:
> [https://github.com/danielthegray/log4j-nobugsample]
> Wrong behavior with the slf4j bridge:
> [https://github.com/danielthegray/slf4j-bugsample]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
