Hi guys, since now tomcat has Log API as a SPI doing 2 is easy ( http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/microwave-core/src/main/java/org/apache/microwave/logging/tomcat/Log4j2Log.java) and just a drop-in jar setup so not sure it needs to be in tomcat default delivery.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-10-25 15:28 GMT+02:00 Mark Thomas <ma...@apache.org>: > 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 > >
