Hi Ralph,
See in between the lines.
Curious to hear what your take is on the classloader usage which is what
is causing my issues.
Paul
On 22/02/2019 18:43, Ralph Goers wrote:
I am not really clear on what you are trying to achieve so this answer is
making some guesses.
A typical tomcat deployment will have a boot class loader, the tomcat class
loader and each web app will have its own class loader. Tomcat’s logging has
to happen using Tomcat’s class loader while the web app uses a combination of
Tomcat’s and the Web Apps.
It sounds like you want:
To use Log4j for tomcat logging.
To use Log4j for application logging.
To incorporate your own appenders for application logging.
Correct
What I am not clear about is if you have any custom stuff you want to include
for Tomcat logging. I am going to assume you don’t.
Correct assumption, I don't need anything custom for Tomcat logging
There are a couple of ways I would try to make this work. First, you have to
remember that in Tomcat the WebApp class loader is searched first before
delegating to the Tomcat class loader and that any classes in the Tomcat class
loader won’t be able to directly access classes in the Web App class loader. If
you place Log4j and your custom appenders in the tomcat class loader and do not
include them in your web app then everything should work. However, if your
custom appenders have dependencies on a bunch of custom code this can get
pretty ugly as they would need to be in tomcat/lib as well.
The custom appenders are standalone, they just have a public static
field that is accessed by code in my webapp.
I tried doing as you described, but to no avail. It seems like the log4j
stuff isn't loaded using the bootstrap/system or common classloader, but
through the Java system classloader. What I don't understand is why the
log4j stuff seems loaded by the Java system classloader and not the
Tomcat classloaders... To my understanding: if any of the
bootstrap/system or common classloaders of Tomcat would be used, all
would be good, as those are all in the webapp classloader hierarchy,
correct?
Another way to deal with this would be to place the log4j jars in both
tomcat/lib and in the web application’s WEB-INF/lib. Tomcat will initialize
using the Log4j jars it finds in tomcat/lib. The web app should use the log4j
jars from WEB-INF lib. In that case you will essentially have two separate
log4j implementations, which is pretty much what you have to do to accomplish
what it sounds like you want.
I haven't tried rolling two full log4j implementations, find that a bit
of waist of resources (@runtime, but also deployment-wise: we'll have
many containers running using this setup)
Also, by default Log4j uses the ClassLoaderContextSelector. This insures that
there are two LoggerContexts - one for tomcat and one for your web app. If you
place everything in tomcat/lib you probably don’t want to use that
ContextSelector. You probably would want to use the BasicContextSelector for
that.
Ralph
On Feb 22, 2019, at 9:27 AM, Paul <pgbak...@gmail.com> wrote:
Tnx
I've also tried myself locally on my laptop (Wind10, Tomcat 9.0.16, log4j2
2.11.2, Java 1.8.0_162) but the exact same problem.
I've also looked at the docs on the Tomcat side: for Tomcat 9 the docs on
logging don't mention this mechanism to use log4j anymore. On the 8.0
documentation it is there, but talks about Log4j 1 and also details how you
need to replace the tomcat-juli(-adapters).jars, which I think is not required
anymore, see this case: https://bz.apache.org/bugzilla/show_bug.cgi?id=58588.
However, that case seems to suggest that the way to replace tomcats internal
logging is through JUL....
So, I gave JUL another shot:
- with all the log4j-core/api/jul/ and a log4j2.properties on the classpath set
through setenv.sh, I'm able to replace the internal logging of Tomcat using
Log4j2. So far so good.
- For the logging from the single webaap/WAR I'll ever deploy in this tomcat
instance, I have custom appenders that have static fields that are accessed
from within the deployed webapp and through the log4j2 appender interface
methods. Hence, log4j2 and the webapp need to use the same classloader
(hierarchy), otherwise they'll be looking at teh same class loaded through
different classloaders, thus different instances of the static field. I've got
log4j2-web.jar and the jar containing my custom appenders both in the
WEB-INF/lib folder of my webapp + a log4j2.properties in the WEB-INF folder,
but then Log4J can't find the custom appenders. If I put the jar with the
custom appenders on the classpath via Tomcat's setenv.sh, Log4J initializes
properly, but the WebApp and Log4j seem to use 2 different classloaders, thus I
run into the problem with multiple instances of the static field
Is there any setup I can use that works in this scenario?
Paul
On 20/02/2019 12:26, Apache wrote:
Ok. I will try it myself with both of those and let you know, but it might take
a couple of days.
Ralph
On Feb 19, 2019, at 11:58 PM, Paul <pgbak...@gmail.com> wrote:
With log4j-web on the classmate the INFO statements you mentioned
disappear, but the problem of internal tomcat logging via log4j isn't
solved.
And I've went through but those links many times, tried everything I could
find there, but no avail
On Tue, Feb 19, 2019, 11:26 PM Remko Popma <remko.po...@gmail.com wrote:
Hi Paul,
Please try adding the log4j-web jar to the classpath:
INFO StatusLogger Log4j appears to be running in a Servlet environment,
but there's no log4j-web module available. If you want better web container
support, please add the log4j-web JAR to your web archive or server lib
directory.
Also, this user manual page may be useful:
https://logging.apache.org/log4j/2.x/manual/webapp.html (and maybe this
one: https://logging.apache.org/log4j/2.x/manual/logsep.html).
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
On Feb 20, 2019, at 1:03, Paul <pgbak...@gmail.com> wrote:
INFO StatusLogger Log4j appears to be running in a Servlet environment,
but there's no log4j-web module available. If you want better web container
support, please add the log4j-web JAR to your web archive or server lib
directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
---
This email has been checked for viruses by AVG.
https://www.avg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
