Referencing Environment Variables in web.xml

Question

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

Answer 1

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
    }

Answer 2

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

Answer 3

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");

Answer 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!

Answer 5

You have to put the env-entry in order :

<env-entry>
  <env-entry-name>maxAmount</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>aString</env-entry-value>
</env-entry>

Else you will have validation error on web.xml

ref: https://community.oracle.com/thread/840452?tstart=0

Answer 6

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