that SLF4J provides an interface called LocationAwareLogger, which Log4J2 supports, so, we can filter the utility class by simply passing the Log Utility Class' FQCN (Fully Qualified Class Name).

My original utility class looked something like this:

public class InternalLogger {



  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);



  public void log(EventLog eventLog) {

    //... get message and logLevel from eventLog

    switch (logLevel) {

      case DEBUG:

        LOG.debug(message);

        break;

      case WARN:

        LOG.warn(message);

For this solution, I declared the Logger class FQCN and added a private helper function to log with a LocationAwareLogger:

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();



  private void locationAwareLog(int level, String message) {

    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);

  }

And changed my old code to call it if supported:

switch (logLevel) {

  case DEBUG:

    if (LOG instanceof LocationAwareLogger) {

      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);

    } else {

      LOG.debug(message);

    }

    break;

  case WARN:

    if (LOG instanceof LocationAwareLogger) {

      locationAwareLog(LocationAwareLogger.WARN_INT, message);

    } else {

      LOG.warn(message);

    }

//...

Unluckily, SLF4J doesn't provide a way to provide the level as an argument (i.e. LOG.log(level, message)). If it did, the code would be a little less verbose.

After implementing this change, logs now accurately report the caller’s line number, significantly improving traceability:

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

Notice the difference: InternalLogger.java:34 versus ActualLogic.java:1059, which indicates a more precise location of the log origin within the application code.

Conclusion

By incorporating SLF4J's LocationAwareLogger, I have transformed our logging system from a source of confusion into a precise diagnostic tool. This change enables accurate reporting of the caller's line number instead of that of the logging utility, greatly enhancing our ability to diagnose issues swiftly and accurately.

This improvement not only streamlines debugging but also reduces response times when addressing software issues.

Developers facing similar challenges should consider this approach to elevate the effectiveness of their logging systems. With clearer and more accurate logs, they can turn what was once ambiguous data into actionable insights, improving both operational efficiency and software reliability. Optimized logging is crucial for meeting the challenges of today’s fast-paced development landscape and ensuring high-quality software outcomes.