Hi Bruno,
On 11.03.2025 15:50, Bruno Melloni wrote:
Thanks, excellent set of links and information!
* [2] is almost identical to what I "used to use" for Tomcat 8 and 10
log4j 2.x logging (the only real difference is the folder names I
chose). I am not sure when, but at some point this solution
stopped working with Tomcat 10 (it still works with Tomcat 8).
I didn't test it on Windows, but on Linux the procedure works.
Note that if you are starting Tomcat as a Windows service via
`tomcat10.exe` (Procrun), then the classpath must be set in the Tomcat
Monitor application `tomcat10w.exe` and the `setenv.bat` file should be
ignored.
* After a lot of troubleshooting I discovered that for Tomcat 10
(using just the apps included with the distribution) I had to also
add
-Djava.uytil.logging.manager=org.apache.logging.log4j.jul.LoggingManager
This property has a slightly different purpose than the procedure above:
it redirect `java.util.logging` API calls to the Log4j API, while the
procedure above redirect Tomcat JULI API calls to the Log4j API.
In the Java world there are lots of logging APIs (each major
application/library seems to have one; Tomcat has Tomcat JULI), but only
a handful of logging implementations (JUL, Logback, Log4j Core 2 and
JBoss LogManager). The trick is to connect each API with the logging
implementation of your choice (or more precisely their native logging
API) by using the most direct bridge available.
Basically currently you have a chain of redirection: Tomcat JULI -> JUL
-> Log4j API, while using the documented procedure you would have a
direct Tomcat JULI -> Log4j API.
We included the basic concepts and many examples of API-to-API bridges
in our Installation Guide[1].
[1] https://logging.apache.org/log4j/2.x/manual/installation.html#concepts
Note: In my previous mail I erroneously suggested setting:
LOGGING_MANAGER="org.apache.logging.log4j.jul.LoggingManager"
It should be (also considering the Windows syntax):
set
"LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.logging.log4j.jul.LoggingManager"
and
-Dlog4j.configurationFile=file:%CATALINA_HOME%\log4j\log4j2-tomcat.xml
to setenv.bat.
Could you use the official `log4j2.configurationFile` property[2] (with
an additional 2)? The old `log4j.configurationFile` property was
deprecated in 2.10.0 and will be removed in the next major release. We
intentionally don't use that property anywhere in our documentation.
[2]
https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationFile
* I also had to replace the "handlers" variable to only include
org.apache.logging.log4j.jul.LogManager in logging.properties.
Simply deleting logging.properties and/or tomcat-juli.jar does not
work as now Tomcat requires those to be present, as the log4j pieces
only allow for those tomcat-juli libraries to forward to the log4j
libraries.
The `tomcat-juli` library MUST be there, since it contains Tomcat's
logging API.
The `conf/logging.properties` file can even be removed.
The only remaining issue is that apparently _log4j 2.20.0 LogManager
does not seem to implement the java.util.logging.Handler interface_.
I am not positive yet, but this does not appear to be a serious
issue. I did notice that it causes an exception when you run
shutdown.bat, and once every time a webapp (any webapp) is loaded onto
Tomcat.
The `j.u.l.Handler` class is the JUL equivalent of a Log4j Core
appender. Since `o.a.l.l.jul.LogManager` bypasses JUL altogether, there
is no need any more for JUL handlers (or the `logging.properties` config
file).
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
