FWIW, Looking at the Tomcat 9.0 code I see the same ServiceLoader code as in Tomcat 8.5, so the log4j-appserver code should still work.
Ralph > On Feb 22, 2019, at 11:27 AM, 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
