dddrecall commented on issue #3774: URL: https://github.com/apache/logging-log4j2/issues/3774#issuecomment-2998528277
> Hi [@dddrecall](https://github.com/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](https://github.com/apache/logging-jdk) subproject (see [apache/logging-jdk#2](https://github.com/apache/logging-jdk/pull/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](https://github.com/qos-ch/slf4j/discussions/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](https://logging.apache.org/log4j/2.x/jakarta.html#replace) for more info. Thank you very much for your suggestions. I will use the log4j-appserver solution to solve this problem -- 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]
