On 17/04/17 13:41, Rainer Jung wrote: > 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.
It is a pity it looks like we'll have to re-introduce the adapter concept to support log4j2 directly but I don't see a way around it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
