Am 17.04.2017 um 11:49 schrieb Rémy Maucherat:
2017-04-15 23:32 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>:
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=or
g.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)?
Ok, so the dependency from extras to log4j is removed just to be added
back 5 minutes later as a real dependency. Interesting !
Personally, I'm probably going to vote "no".
The idea here is not to remove some dependency but to fix the "wrong
location info" problem/bug.
Or do you see a new dependency creeping in here? The patch does
introduce a compile time dependency to log4j but not a runtime
dependency unless you are using the optional adapters jar (to fix the
location info bug).
I still do not see a better way to fix the problem.
Or maybe I misunderstood you.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
