SLF4J / SLF4J-511 [Reopened] DefaultLogEventBuilder causes incorrect location information to be logged
============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-511 ============================== 1 comment ------------------------------ Ralph Goers on 19/Jun/21 7:14 PM Yes, I've seen them but they are making the assumption that the logging API being used by the user is SLF4J and not something wrapping it. Consider a user who wants to create their own custom wrapper for whatever purpose. I've seen some people do it to create a more "rigid" API such as {code:java} Audit.logEvent(auditEvent); {code} The may want to include the location of the caller so in the logEvent method they would expect to be able to do something like. {code:java} logger.atInfo().withFQCN(MY_FQCN).log(() -> msgSupplier(auditEvent); {code} {code:java} logger.atInfo().atLocation(locationSupplier).log(() -> msgSupplier(auditEvent); {code} or just {code:java} logger.atInfo().atLocation(calcLocation(2).log(() -> msgSupplier(auditEvent); {code} where calcLocation calls StackWalker and returns the caller's StackTraceElement or the FQCN or location supplier would be provided by the wrapper to provide the StackTraceElement of the caller. These would then be used by the implementation to determine the caller's information. It is hard to predict why people create wrapper APIs. Some have good reasons, some not so good. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59) _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
