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.go...@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 <pgbak...@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.go...@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 <pgbak...@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 <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 > >> <mailto:log4j-user-unsubscr...@logging.apache.org> > >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >> <mailto: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 > >
