2016-10-26 11:38 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>: > Note that for the jul bridge to work, the Log4J2 jar files have to be put > onto the CLASSPATH (otherwise the Log4J2 jul LogManager can't be used) and > so the resource pointing to the custom LogEventFactory must sit there as > well. > > But it seems one of my early tests was wrong. The custom factory is *not* > being loaded by a webapp local Log4J2 instance. At least not with the setup > I originally described. > > So putting the factory and the log4j2.component.properties file into the > tomcat-juli.jar should be transparent (to webapps and also the setups which > do not use Log4J2 at all) and would be one solution to the original problem > of wrong location info. I still need to test behavior if webapps use juli > as well. > > Whether we also want to directly support Log4J2 with an SPI provided Log > implementation that delegates to Log4J2 is still open. Personally I find it > somewhat cleaner to point to the Log4J standard way (adding the jul bridge > and other log4j jar files as well as the LogManager system property) > instead of needing to activate/add a separate TC jar file containing the > new Log impl and SPI meta data. It seems the only way to activate the log > impl via SPI is adding the containing jar to the class loader search path > (likely CLASSPATH). > > One of the problems of using a standard logging framework was class conflicts (the webapps can see a shared log4j, they can try to override it, but it could cause issues).
Rémy
