log4j-jul java.util.logging.Logger#logp is not working

[dddrecall]

Description

[A clear and concise description of what the bug is.]

Configuration

Version: 2.24.3

**Operating system: mac 14

JDK: 17

Logs

[2025-06-23 10:02:04,535] [INFO] [main] [org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:168)] - Initializing ProtocolHandler ["http-nio-7713"]
[2025-06-23 10:02:05,388] [INFO] [main] [org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:168)] - Starting service [Tomcat]

Reproduction

It seems that the logpg method will directly discard the input parameters: sourceClass, sourceMethod

tomcat[tomcat-embed-core-10.1.41.jar]

org.apache.juli.logging.DirectJDKLog

Tomcat seems to be able to use it org.apache.logging.log4j.jul.ApiLogger#logp(java.util.logging.Level, java.lang.String, java.lang.String, java.lang.String) method

[ppkarwasz]

Hi @dddrecall,

Thank you for your report!

You're absolutely right — log4j-jul currently does not support passing location information programmatically. The primary reason is historical: when the original code was written, the Log4j API didn't yet offer methods that accepted a StackTraceElement. Since this functionality has been very rarely requested (yours might actually be the first — great catch! 💯), we haven't prioritized updating the implementation in the 2.x series.

That said, we've already implemented this feature in our incubating Apache Log4j bridges for JDK logging subproject (see apache/logging-jdk#2). This project aims to provide:

• A universal jdk-logmanager, as discussed in Add a universal `j.u.l.LogManager` implementation qos-ch/slf4j#429. This will allow you to hardcode a single java.util.logging.LogManager implementation in your application, while still letting users redirect JDK logging to various backends by simply swapping out JARs at deployment time.
• Correct and consistent location detection for all supported logging APIs.
• Compatibility with all Log4j API 2.x implementations — including both Log4j Core 2.x and the upcoming 3.x.
• A baseline targeting the latest JRE that modified the JDK logging APIs — currently Java 9, which introduced System.Logger and extended java.util.logging.Logger.

We plan to make the first release of that subproject around the time Log4j Core 3.x is released or shortly thereafter. To focus our limited resources on this effort, we don't currently plan to make further changes to log4j-jul. However, if you'd like to see this functionality added to log4j-jul sooner, contributions are welcome — we'd gladly review a PR!

⚠️ Note on Location Information

JDK logging APIs are infamously unreliable when it comes to location detection — especially when bridging between APIs. In your specific scenario:

• Log events generated by Tomcat using Tomcat JULI (a fork of Apache Commons Logging) are routed to java.util.logging.
• The log4j-jul bridge then forwards them to the Log4j API.

Even if log4j-jul did support your request, some data — like the line number of the original log statement — would still be lost in translation.

If accurate location data is important for your application, we recommend bypassing JUL altogether. You can do this by adding log4j-appserver to your application. It's automatically detected by Tomcat JULI and lets you log directly to the Log4j API, skipping JUL entirely. See Replacing the Application Server Logging Subsystem for more info.

[dddrecall]

Thank you very much for your suggestions. I will use the log4j-appserver solution to solve this problem

[dddrecall]

Hi @dddrecall,

Thank you for your report!

You're absolutely right — log4j-jul currently does not support passing location information programmatically. The primary reason is historical: when the original code was written, the Log4j API didn't yet offer methods that accepted a StackTraceElement. Since this functionality has been very rarely requested (yours might actually be the first — great catch! 💯), we haven't prioritized updating the implementation in the 2.x series.

That said, we've already implemented this feature in our incubating Apache Log4j bridges for JDK logging subproject (see apache/logging-jdk#2). This project aims to provide:

• A universal jdk-logmanager, as discussed in Add a universal j.u.l.LogManager implementation qos-ch/slf4j#429. This will allow you to hardcode a single java.util.logging.LogManager implementation in your application, while still letting users redirect JDK logging to various backends by simply swapping out JARs at deployment time.
• Correct and consistent location detection for all supported logging APIs.
• Compatibility with all Log4j API 2.x implementations — including both Log4j Core 2.x and the upcoming 3.x.
• A baseline targeting the latest JRE that modified the JDK logging APIs — currently Java 9, which introduced System.Logger and extended java.util.logging.Logger.

We plan to make the first release of that subproject around the time Log4j Core 3.x is released or shortly thereafter. To focus our limited resources on this effort, we don't currently plan to make further changes to log4j-jul. However, if you'd like to see this functionality added to log4j-jul sooner, contributions are welcome — we'd gladly review a PR!

⚠️ Note on Location Information

JDK logging APIs are infamously unreliable when it comes to location detection — especially when bridging between APIs. In your specific scenario:

• Log events generated by Tomcat using Tomcat JULI (a fork of Apache Commons Logging) are routed to java.util.logging.
• The log4j-jul bridge then forwards them to the Log4j API.

Even if log4j-jul did support your request, some data — like the line number of the original log statement — would still be lost in translation.

If accurate location data is important for your application, we recommend bypassing JUL altogether. You can do this by adding log4j-appserver to your application. It's automatically detected by Tomcat JULI and lets you log directly to the Log4j API, skipping JUL entirely. See Replacing the Application Server Logging Subsystem for more info.

Thank you very much for your suggestions. I will use the log4j-appserver solution to solve this problem