ppkarwasz opened a new issue, #20: URL: https://github.com/apache/logging-jdk/issues/20
Instead of adding a modernized version of [`o.a.l.l.jul.LogManager`](https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-logmanager), we could create a **universal** `j.u.l.LogManager` implementation — as discussed in qos-ch/slf4j#429. This implementation would forward log events from both `j.u.l.Logger` and `j.l.System.Logger` to at least the **Log4j API** and **SLF4J**, depending on what's available at runtime. ### ✅ Benefits - **Broader interoperability** Logback users would benefit directly, as there is currently no `j.u.l.LogManager` implementation that routes log events to SLF4J directly. Today, they must route through Log4j as an intermediary. - **Modular and runtime-flexible** A `ServiceLoader`-based design would allow applications and containers to **hardcode the LogManager implementation** in their initialization scripts or main class, while still letting users decide which logging backend (JUL, Log4j Core, Logback, etc.) to plug in. - **Practical workaround for JDK limitations** This approach effectively serves as a **community-driven workaround for [JDK-8262741](https://bugs.openjdk.org/browse/JDK-8262741)** — a long-standing and likely unresolvable limitation in the JDK that prevents flexible replacement of the `LogManager`. -- 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]
