On 25/10/2016 14:17, Rainer Jung wrote: > Hi everyone, > > when using TC 8.5 with the Log4J2 jul bridge the location info in the > Log4J output points to the juli class DirectJDKLog instead of the Tomcat > class with the juli log call. Only the category/logger name is correct: > > %c: org.apache.catalina.core.StandardServer (Example, correct) > %C: org.apache.juli.logging.DirectJDKLog > %l: org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:179) > %M: log > %F: DirectJDKLog.java > %L: 179 > > The jul bridge does not try to fully populate al possible location info, > but instead only the category name. Log4J then later gets the log > location from the stack frame that calls the jul bridge which always > gives org.apache.juli.logging.DirectJDKLog. > > It seems we either need to directly call the jul bridge without an > intermediate logging impl class, or the Log4J2 jul bridge must be made > more complex. > > Any opinion? Ideas?
I did look at whether or not we could remove the use of DirectJDKLog - essentially reducing JULI to the custom LogManager. My conclusion at the time was it was possible but was a whole lot of effort for very little benefit. Maybe this tips the balance? The other option would be to provide a dedicated log4j2 adadptor - maybe along with appropriate adapters for other logging frameworks as well. > I know that the location info is expensive to get, but failing to > support the correct location info is IMHO bad. The old adapter solution > supported correct location info in log4j. I think we have two options: 1. Code to just java.util.logging as sufficient and let the logging frameworks deal with hooking in to java.util.logging. This is essentially the option that removes code. 2. Provide an adaptor for at least log4j2 and possible other frameworks. This is essentially the option that adds code. Option 1 means less code but less flexibility. Option 2 is more code but what we get in return is more flexibility maybe implementation options for better performance. Another advantage of 1 is that it removes JULI as a dependency from much of out code. This could make it simpler for others to re-use. Personally, I lean towards 1. but I'm not going to object if someone wants to pursue 2. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
