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".
Rémy
