2016-10-26 11:50 GMT+02:00 Rémy Maucherat <r...@apache.org>: > 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). >
If I got the original issue right, it is only about allowing a user to replace the default (JULi) so should be acceptable, no? > > Rémy >
