logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul <pgbak...@gmail.com>
Subject Re: Application Server integration in Tomcat
Date Fri, 22 Feb 2019 21:05:37 GMT
I'll double-check again, but I'm pretty confident the class is there only
once

On Fri, Feb 22, 2019, 9:33 PM Ralph Goers <ralph.goers@dslextreme.com>
wrote:

> If there the class exists in only one jar/directory then that class will
> only be loaded once by the class loader that manages the jar or directory.
> The only way you can have two instances of the class is if it is present in
> two different class loaders. In the case of Tomcat, that would mean it has
> to be present in both WEB-INF/lib or WEB-INF/classes and tomcat/lib.
>
> I am still in the process of testing log4j-appserver with Tomcat 9. I will
> let you know what I find.
>
> Ralph
>
> > On Feb 22, 2019, at 12:30 PM, Paul <pgbakker@gmail.com> wrote:
> >
> > The 'error' I get is that the static field on my custom appender class is
> > null when accessed from my webapp, long after log4j is initialized, while
> > the appender constructor that log4j called sets is value.
> >
> > And the access to that static field happens long after log4j is
> initialized.
> >
> > So my conclusion is that the appender class is loaded by multiple
> > classloader
> >
> > Maybe it's using the java system classloader cause I'm using log4j-jul
> (as
> > log4j-appserver doesn't work)?
> >
> > Paul
> >
> > On Fri, Feb 22, 2019, 7:27 PM Ralph Goers <ralph.goers@dslextreme.com>
> > wrote:
> >
> >> Tomcat’s class loader will be a parent of the web app class loader. That
> >> means the log4j-related classes placed in the tomcat class loader won’t
> be
> >> able to access anything in your web-app class loader. But your
> application
> >> should have no problem accessing them in tomcat’s class loader provided
> you
> >> don’t also have them in your web-app.  That said, I haven’t looked at
> >> Tomcat 9 yet. It is possible that they have an additional class loader
> that
> >> is not in the parent hierarchy of the web-app class loader. If that is
> the
> >> case your web app wouldn’t be able to access it. But then again, it
> >> wouldn’t find Log4j either.
> >>
> >> What error do you get when you try to access the static fields?
> >>
> >> Ralph
> >>
> >>> On Feb 22, 2019, at 11:13 AM, Paul <pgbakker@gmail.com> wrote:
> >>>
> >>> 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 <pgbakker@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 <pgbakker@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.popma@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 <pgbakker@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-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>> ---
> >>>>> This email has been checked for viruses by AVG.
> >>>>> https://www.avg.com
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> <mailto:log4j-user-unsubscribe@logging.apache.org>
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >> <mailto:log4j-user-help@logging.apache.org>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message