Coming back to this.
Reminder:
- in TC 8.5 we removed explicit support for Log4J(2)
- we direct users at the Log4J2 JUL bridge
- the Log4J2 JUL bridge works by adding the additional Log4J2 jar files
to the CLASSPATH and setting LOGGING_MANAGER to
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
Now there's a problem: the log4j2 implementation of retrieving location
info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli
sitting between the real jul classes and log4J2 and so always results in
org.apache.juli.logging.DirectJDKLog as location of the log event
instead of the real class containing the log statement.
Of course location info patterns are not recommended for performance
reasons, nevertheless I think they should work correctly for debugging
purposes.
One suggested solution was:
- add a org.apache.juli.logging.Log impl that delegates to Log4J2
(instead of the JUL bridge)
and
- add a Log4jLogEventFactory that additionally skips our DirectJDKLog
when looking for the location info in the stack.
I implemented this. See the patch for 8.5 at
http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
The way I did it, is adding back a tomcat-juli-adapters.jar, which
contains the above two classes. Adding this instead of the Log4J2 JUL
bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no
changes to LOGGING_MANAGER) result in Log4J2 being used and logging with
correct location info.
Would that make a useful addition for TC 8.5 (and 9)?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
