Hi Mark, On Sat, 11 Jun 2022 at 09:48, Mark Thomas <ma...@apache.org> wrote: > > Why can't web applications just use: > > https://logging.apache.org/log4j/2.x/log4j-jul/index.html > > ?
Web applications usually contain libraries that use a variety of logging APIs (Spring uses JCL, Hibernate JBoss Logging, others use SLF4J API or Log4j2); `java.util.logging` is almost never used. The jars for these APIs are distributed in the WAR archive, allowing the application to work on several servlet containers. Frameworks such as Spring Boot or the developers of the app themselves take care of bridging all these APIs to a single one. Using the `LogManager` implementation in `log4j-jul` would accomplish the job of forwarding Tomcat server's logs to Log4j2, but it will also hijack the logs from webapp libraries that use `java.util.logging`. So one would end up with several mixed up logging contexts: one with Tomcat server's logs + JUL logs from the webapps and one context for each web application. The purpose of `log4j-appserver` is to forward Tomcat server's logs directly to Log4j2, without messing up with the default `ClassLoaderLogManager`. The `ClassLoaderLogManager` allows every web application to forward JUL logs to its own copy of the Log4j2 API. This provides an order, yet not ideal situation, where all logs from the server itself uses a copy of `log4j-api` in the common/server classloader, while each application uses its own copy of `log4j-api`. > There seem to be more logging frameworks than application servers these > days. I don't really want to start down the road of adding a JUL > implementation for every one of them. There aren't so many logging frameworks if you count the implementations (not the APIs). Basically there is Logback and Log4j2 Core, while JBoss LogManager is used in full Java EE servers. The APIs are strongly connected (there is a bridge between any major API and Log4j2 Core or Logback), so adding a single JULI implementation would be enough to use any logging backend. This sums up to about 200 lines of code: https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-appserver/src/main/java/org/apache/logging/log4j/appserver/tomcat/TomcatLogger.java The SLF4J implementation is similar (https://github.com/tomcat-slf4j-logback). I think it would be nice to see these two in the Tomcat project instead of Log4j2 and a Github repository. The main advantage I see is that I could enhance them with the features present in the standard Tomcat JULI implementation (basically the `${classloader.*}` variable substitution). Piotr PS: Contrary to what I wrote in my first mail, if a web application contains the `log4j-api.jar` it is overly complicated to forward its logging to another copy of `log4j-api.jar` in the common classloader, without inverting the delegation model. Having a single `log4j-api/log4j-core` driving the logging of several web applications is beneficial: each web app can have a different logging configuration, but due to the architecture of Log4j2 Core, each log file will be opened at most once. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
