Tag Archives: log4j

java.lang.IllegalStateException: Web app root system property already set to different value: ‘webapp.root’ = [/ApplicationPath1] instead of [/ApplicationPath2] – Choose unique values for the ‘webAppRootKey’ context-param in your web.xml files!

Recently I have deployed two J2EE web application in tomcat web server. Both application uses the log4j. Tomcat server is up and running with no issues.

But at regular interval, one of the J2EE web application was going down. I was digging into the logs and google to find the solution. At regular times, it made us to enter into the tomcat manager page to start the application manually which was down.

Then I have identified the following exception message

java.lang.IllegalStateException: Web app root system property already set to different value: 'webapp.root' = [C:\Program Files\Apache Software Foundation\Tomcat7.0.57\webapps\application1\] instead of [C:\Program Files\Apache Software Foundation\Tomcat7.0.57\webapps\application2\] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!
at org.springframework.web.util.WebUtils.setWebAppRootSystemProperty(WebUtils.java:156)
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:117)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:46)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4994)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5492)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1245)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1895)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Root cause:

Due to the business requirement, we copied the application1’s code base and created the application2’s code base.
I gave unique names wherever necessary in the configuration files. But still I encountered the above error message. After spending long time, I got the below information about the spring framework

“WARNING: Some containers (like Tomcat) do not keep system properties separate per web app. You have to use unique “webAppRootKey” context-params per web app then, to avoid clashes. Other containers like Resin do isolate each web app’s system properties: Here you can use the default key (i.e. no “webAppRootKey” context-param at all) without worrying. ”

It turns out that the webAppRootKey is a Spring context parameter. It exposes the web application’s root directory as a system property. So, it is the value of the webAppRootKey that provides the name for the system property to use. That’s fine if you’ve just got one webapp in Tomcat. Spring will just choose a default value for this (app.root) and off you go. However, as the warning above notes, Tomcat does not keep system properties separate per webApp. This means that when we get to the second application, the same system property (app.root) is being set to a new value (our second application’s root directory, rather than the first!)

The reason this is occurring at all is that Log4JConfigListener is trying to set the webAppRootKey in both cases. This allows log4J to place log and config files in directories relative to the application root directory, rather than in a fixed path.

I decided the easiest thing was just to use a non-default name for the webAppRootKey for each of my applications.

That is, I fixed this by placing the following context-parameter into each of the web application’s web.xml files:


This fixed the problem