Referencing Environment Variables in web.xml

Solution 1:

You can use Ant-style variable substitution in any of the tomcat xml config files, such as:

<servlet-mapping>
    <servlet-name>mvc-dispatcher</servlet-name>
    <url-pattern>${foo}</url-pattern>
</servlet-mapping>

Where foo is a Java System Property (sysprop).

You can't use OS Environment Variables (envvars) directly, I think...

To use envvars, you can put

set "CATALINA_OPTS=-DsomeJavaSysProp=%SOME_OS_ENVVAR%"

in bin/setenv.bat (or similarly in bin/setenv.sh for *nix). You may need to create that file. Tomcat will run this file when it starts.

As CATALINA_OPTS is an envvar (as opposed to a command line option), it should not be visible by other users on the system (save ancient Unixes), though I haven't tested this.

http://tomcat.apache.org/tomcat-7.0-doc/config/

If you are using Spring, you can create a <context:property-placeholder/> bean and then directly use envvars or sysprops in Spring XML config files (though not web.xml).

Solution 2:

i think you don't want to use environment variables (which i think are not accessible from web.xml), but environment entries [1, 2]. like so:

<env-entry>
    <env-entry-name>Bla/SomeFilePath</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>/opt/bla</env-entry-value>
</env-entry>

you can use SomeFilePath like:

InitialContext ic = new InitialContext();
String s = (String) ic.lookup("java:comp/env/ejb/Bla/SomeFilePath");

Solution 3:

Basically, you don't do it that way. The web.xml should contain default values for things, yes, but you should override them when actually doing the deployment. If you're deploying to Tomcat, you do this by including appropriate entries in the context.xml that you use for the deployment. For example:

<Context path="/app">
    <!-- For things described by webapp parameters -->
    <Parameter name="foobar" value="grill" />

    <!-- For things described by environment entries -->
    <Environment name="Bla/SomeFilePath" type="java.lang.String"
            value="/opt/bla" />
</Context>

Other containers will have their own mechanisms for doing this so. You'll have to look up their documentation (or make your request for help more focussed).

Solution 4:

Environment variables can be accessed in xml files like this:

${env.ENVIRONMENT_VARIABLE_NAME}

Obviously there may be issues with user account settings and access issues, but i have tried with system variables and it works!