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>
