Am 26.10.2016 um 15:32 schrieb Romain Manni-Bucau:
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?
Yes, the original problem is, that we removed juli-adapters and claim
that using Log4J2 as an alternative log framework for Tomcat now works
out-of-the box using the jul support in Log4J2.
See https://bz.apache.org/bugzilla/show_bug.cgi?id=58588 and the
corresponding changelog entry for 8.5.4:
58588: Remove the JULI extras package from the distribution. It was
only useful for switching Tomcat's internal logging to log4j 1.2.x and
that version of log4j is no longer supported. No additional Tomcat code
is required if switching Tomcat's internal logging to log via log4j 2.x.
(markt)
When actually using this I noticed, that the location info in the log
statements is wrong and can't be fixed with TC or Log4Js out-of-the-box
features. Due to your hints, we now know how to fix it by adding a
LogEventFactory and making it available to Log4J2 using a properties
files as a class loaded ressource.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
