2014-12-09 1:24 GMT+03:00 Rainer Jung <[email protected]>:
>
>> <skipped...>
>
> Adding to self: not only does the out-of-the-box integration need the
> various log4j2 jar files on the CLASSPATH, but if you want to configure it
> using the config file search as a resource via classloader, then again it
> must be found by the system class loader. But since the webapp loaders
> delegate first to the system class loaders, the jar files and the config
> file will IMHO impact the wanted isolation of the webapps.
>
> Using the "traditional" juli-adapters plus original factory approach, lets
> us keep the jar files and config file in the common loader. The common
> loader by default is not queried early by the webapp loader, but instead
> only as a fallback.
1. If I understand correctly, currently there is no such difference
between the system class loader and common class loader. The web
application overrides any of them, so there is no difference.
I mean this change (7.0.51), in case if you missed it,
<fix>
<bug>55943</bug>: Improve the implementation of the class loader check
that prevents web applications from trying to override J2SE
implementation classes. As part of this fix, refactor the way a null
parent class loader is handled which enables a number of null checks and
object creation calls to be removed. Note that this change means that,
by default, the web application class loader is now a higher priority
for loading classes than the system class loader. (markt)
</fix>
Also,
http://tomcat.apache.org/migration-7.html#Tomcat_7.0.x_noteable_changes
2. Regardless of your solution, you cannot perfectly hide Log4j or
Log4j2 from a web application.
For example, if a web application uses commons-logging, it will
autodetect Log4j and switch to it. It may ruin logging configuration
of this web application as it will ignore
WEB-INF/classes/logging.properties and will start looking for Log4J
configuration file.
Being able to overwrite the library at web application level is a good
point (thank you for reminding it),
but personally I do not like such ambiguities in configurations and I
am ready to expect nasty surprises. I cannot say whether it works for
Log4j[N] without actual testing.
3. If Log4j[N] is used to configure Tomcat logging, I think that it
means that the site administrator is a fan of Log4j and would like all
applications as well to be consistently logging to log4j[N]. It this
case it is up to him to prepare configuration for the whole server,
including tuning configurations in all web applications that are
deployed on such server.
In this scenario if Log4j2 is configured as JUL logging it means that
this allows to configure not only Tomcat itself, but also those other
applications and libraries that log to JUL directly.
A caveat with Log4j recipe is that you cannot turn off JUL logging.
The JUL logging still exists in Java and some web application or
library may be using it. The Log4j recipe in our logging-howto says
to create an empty logging.properties file. That is a trick to silence
JUL, but not a real solution if something is really using it.
This is the reason why I would recommend plugging log4j2 into JUL. I
do not have real experience though. Thus far I prefer to use our JULI
(and plan to work on extending it if it ever does not meet my needs).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
