Am 26.10.2016 um 08:33 schrieb Romain Manni-Bucau:
2016-10-26 8:26 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>:
Am 25.10.2016 um 22:40 schrieb Romain Manni-Bucau:
2016-10-25 22:35 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>:
Am 25.10.2016 um 17:07 schrieb Romain Manni-Bucau:
I'm not sure though, how dangerous this is due to possible effects on
Log4J2 in some webapp. IMHO the alternative LogEvent and LogEventFactory
impl must be made available for Tomcat use already in the CLASSPATH. The
server loader could already be too late. That means it is also visible to
any webapp. And activating it is done either via a system property, or a
resource named log4j2.component.properties which contains the property
Log4jLogEventFactory=org.apache.juli.JuliLogEventFactory
Again this resource IMHO must reside in the CLASSPATH. So both ways of
activating the alternative LogEvent impl also activate it for any Log4J2
in
any webapp.
True or not, nothing prevents to run it in a logger classloader to
isolate
from webapp. That said if you want tomcat to log with log4j2 you likely
also want the webapps to do the same IMO. Also tomcat has a classloader
context selector so config can be per webapp or at least hook is there for
that.
I was more concerned about a webapp that does not use juli, but uses
Log4J2 directly (or via SLF4J etc.). We should not disturb the behavior of
such a webapp by our Tomcat log setup.
Yes Tomcat is not yet able to filter resources by classloader (Loader could
get a config for that with defaults, we do it in tomee for slf4j and
several specs for instance)
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).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
