You didn’t say if you also have a log4j2.xml file in tomcat/lib. If you log something before the two web apps start I am certain that it would use the log4j2.xml in tomcat/lib. I will have to look at the code that loads the configuration file to determine which ClassLoader it will use when the call is made from a web app. If it uses the thread context class loader then that could cause the problem.
Ralph > On Oct 4, 2017, at 3:13 PM, billok...@gmail.com wrote: > > Hi, > > we have multiple webapps, say, webapp1 and webapp2, that use a shared apache > lib (say commonLib, which also uses log4j logging) that deployed as jndi > resource in tomcat (thus was put in tomcat/lib), and followings are our log4j > jars deploy location: > > tomcat/lib: > - log4j-core.jar, log4j-api.jar > - commonLib.jar > > webapp1 and webapp2, in /WEB-INF: > - classes/log4j2.xml > - lib/log4j2-web.jar > > When loading, the ClassLoaderContextSelector correctly uses the > webappClassloader to load the log4j config for webapp1 and webapp2. But for > the commonLib loggerContext, depending on which webapp got loaded first, the > commonLib loggerContext will either be using > webapp1/WEB-INF/classes/log4j2.xml > or > webapp2/WEB-INF/classes/log4j2.xml > > This poses the problem that if say the commonLib loggerContext is using > webapp1/WEB-INF/classes/log4j2.xml > > then webapp1 got undeployed, then the commonLib loggerContext will be > referencing a no longer existed config file. > > any advise on how to handle or resolve the config issue for shared lib > loggerContext that uses log4j? > > > Thanks! > Bill > > > --------------------------------------------------------------------- > 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