log4j-appserver module migration

["Piotr P. Karwasz" <pi...@gmail.com>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: log4j-appserver module migration

["Piotr P. Karwasz" <pi...@gmail.com>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: log4j-appserver module migration

[Mark Thomas <ma...@apache.org>]

Why can't web applications just use:

https://logging.apache.org/log4j/2.x/log4j-jul/index.html

?

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.

Mark


On 10/06/2022 20:12, Piotr P. Karwasz wrote:
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org