40

I get this error message

[ SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener java.lang.IllegalStateException: Web app root system property already set to different value: 'webapp.root' = [C:\Users\jaanlai\Documents\NetBeansProjects\absSovellus\build\web] instead of [C:\Users\Administrator\Documents\NetBeansProjects\keycard2\build\web] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!

It's odd, because I don't have any webAppRootKey defined in my files. What is it?

Improve this question
1

5 Answers 5

Reset to default
68

The webAppRootKey is a context parameter that Spring uses in a couple of places. In this case, it's being used by the Log4jWebConfigurer. It exposes the webapp root as a system property that can be used in log4j configuration files, something like this:

log4j.appender.testfile.File=${webapp.root}/WEB-INF/testlog.log

You would use this if you, for some reason, wanted to locate your logs relative to your webapp root.

The problem that you're running into is that some containers (notably Tomcat) don't maintain a per-webapp mapping of system properties. When you don't specify a webAppRootKey, Spring defaults it to webapp.root. Since you're running two apps in the same container, the second app you're trying to start up sees that the webAppRootKey is already set (via the default), and throws an error. Otherwise, the webAppRootKey would be set incorrectly, and you could end up with logs from one webapp in another webapp.

You can specify a different webAppRootKey using context parameters in your web.xml like so: 

<context-param> <param-name>webAppRootKey</param-name> <param-value>webapp.root.one</param-value> </context-param>

And

log4j.appender.testfile.File=${webapp.root.one}/WEB-INF/testlog.log

in your log4j. This should take care of the conflict.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Note we had the same problem with Websphere v8, and your solution fixed the issue. (don't want others to think the problem is only with Tomcat)
I also had this problem on JBoss, and your solution worked for me.
@MichaelLucas Did the issue on Websphere v8 affect anything besides logging?
@indybee ... no I don't think so. It was a long time ago so hard to remember, but I think it only affected log4j.
52 
<context-param> <param-name>log4jExposeWebAppRoot</param-name> <param-value>false</param-value> </context-param>

...

This solved the problem for me. Credit to:- http://forum.springsource.org/archive/index.php/t-32873.html

Improve this answer

2 Comments

nice, I was going to define a property in maven and then filter web.xml. But then it wouldn't work in development where I use mongrel eclipse plugin to start tomcat with my webapps.
63 v 52 v 18 v alsoRans, on q of 38, as of 20191114.
19

It looks like you have several webapps with default Log4jConfigListener configuration in your application server.

Default behaviour for Log4jConfigurationListener is to expose webapp root as a system property named webapp.root, to allow you to use it when specifying log file locations. However, if system property with the same name already exists, it throws an exception.

You can either configure per-application names for that system property using <context-param> named webAppRootKey, or disable exposing of the system property by setting Log4jConfigListener's <init-param> named log4jExposeWebAppRoot to false.

See also:

Improve this answer

3 Comments

Can this prevent application to run, giving 404 - the requested source is not available?
@michaeljackson4ever: I guess no. After all, you can always check it by removing Log4jConfigListener.
I'm having the problem that the application does not run. Setting the root key did not help.
3

Just in case anyone else has done the above without getting rid of the problem:

Our webapp had the webAppRootKey set correctly, but I still got the exception above. Restarting Glassfish and redeploying the same war-file worked, go figure.

Improve this answer

Comments

2

If you use logback instead of log4j and get the same error, this solves it:

<context-param> <param-name>logbackExposeWebAppRoot</param-name> <param-value>false</param-value> </context-param>
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.