Hello, In the new major Log4j2 3.x version the Apache Logging Project is looking for some better suited maintainers for 3rd party integration plugins[1].
One of the plugins that is looking for a new home is `log4j-appserver`[2]. It contains an implementation of Tomcat JULI and of Jetty's internal logging system. However, since the migration of Jetty to SLF4J2 in the 10.x series the latter will be discontinued. It's a low-maintenance module, but if you were willing to accept into the Tomcat codebase, I could help resolving any issues that might be posted against it. There are also a couple of Tomcat specific extensions that didn't end up in Log4j (e.g. the PR logging-log4j2/#731 [3]), because the project is already bloa^H^H^H^Hfull of features. Other features can not even be implemented properly, without the collaboration of the Tomcat project. For example I don't see any solution that would allow a web application to: 1. contain `log4j-api` and `log4j-core` in the WAR file, so that it can run properly in other servlet containers, 2. switch easily to another Log4j 2 API implementation, when running under Tomcat. By easily I mean: without modification of the WAR file (either physical or through a `Resources` context configuration) and without changing the classloader delegation model. Having access to the `org.apache.tomcat` package hierarchy (and the automatic delegation to the common classloader it provides) on the other hand, I could write a simple Log4j2 provider that delegates the logging from the `log4j-api` copy included in the WAR file to a `log4j-api` copy included in the server's classloader. Piotr [1] https://lists.apache.org/thread/3b4tn6t7zbhm66cw8yx8h8g26tyy50dj [2] https://logging.apache.org/log4j/2.x/log4j-appserver/index.html [3] https://github.com/apache/logging-log4j2/pull/731 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
