Referencing Environment Variables in web.xml

Viewed 96424

I'm pre-packaging a JSP web-app that relies on some file path settings found within web.xml. These settings are unknown at packaging time, because they reference a path the customer will set when deploying the entire application (of which the web-app is a management interface).

It seems that the easiest way to avoid tokens and file modifications in my installer script, is to ask the user for an install location, set this location as an environment variable (e.g JAVA_HOME), and have web.xml always reference that variable.

Is there a way to reference an environment variable value from within web.xml? Google searches lead to the J2EE method of SETTING environment variables from ejb xml files. This is not what I'm looking for.

7 Answers

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).

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!

I'm not totally clear on your limitations, but just maybe you can do this (I'm assuming that it's an init-param you're trying to configure):

1) Leave the variable unspecified in web.xml
2) Create a ServletContextListener and add that to your application
3) Listen for the initialization of your servlet
4) Set the init-param for the servlet at that point

I tried this with a similar problem, but it failed for me because it turned out that the 3rd party servlet (which I also didn't want to mess with) wasn't actually behaving as a servlet at all, so the context never got initialized. But maybe it has a chance here...

If you're using Spring - you could pipe FilterConfig through ConfigurableBeanFactory.resolveEmbeddedValue to enable property placeholders interpolation support in web.xml.

Proxy class for make FilterConfig parameters resolvable.

public class ResolvableFilterConfig implements FilterConfig {

    private final FilterConfig source;
    private final ConfigurableBeanFactory resolver;

    public ResolvableFilterConfig(FilterConfig source, ConfigurableBeanFactory resolver) {
        this.source = source;
        this.resolver = resolver;
    }

    @Override
    public String getFilterName() {
        return source.getFilterName();
    }

    @Override
    public ServletContext getServletContext() {
        return source.getServletContext();
    }

    @Override
    public String getInitParameter(String name) {
        final String value = source.getInitParameter(name);
        return resolver.resolveEmbeddedValue(value);
    }

    @Override
    public Enumeration<String> getInitParameterNames() {
        return source.getInitParameterNames();
    }
}

Filter implementation sample code

    @Override
    public void init(FilterConfig config) throws ServletException {
        // configure
        final ServletContext servletContext = config.getServletContext();
        final AbstractApplicationContext aac = (AbstractApplicationContext) getRequiredWebApplicationContext(servletContext);
        final ConfigurableBeanFactory beanFactory = aac.getBeanFactory();
        config = new ResolvableFilterConfig(config, beanFactory);
        // ... do the rest
    }
Related