Is using VM arguments for servlet configuration 'clean'?

Question

This relates to this answer: System.getProperty("catalina.base") There can be scenario where client may use any other server

another server-independent system property yourself, you can set as a VM argument.

-Dconfig.location=/path/to/folder

In case of Tomcat, you can set it as JAVA_OPTS environment variable, or edit the catalina.bat startup file or edit the Windows Service settings (when it's installed as Windows Service), etc. Other servers supports similar constructs as well.

Is this considered 'clean'? We've been doing this for years, just want to know if this is acceptable, or there is a better way to configure runtime environment.

Answer 1

My understanding is that "more clean" would be using either <servlet-param> <init-param> in web.xml or some kind of IoC solution, like Spring.

Answer 2

I feel this is not the cleanest of ways to attain what you want. You can use the web.xml init params or servlet params tags.
Another way is using properties file or an XML configuration file.

Answer 3

It feels maybe dirty, but there are apart from putting it in the classpath really no better ways if the requirement is to untouch the WAR whenever you want to change the location of external configuration files.

If untouching the WAR is not a strict requirement and rebuilding the WAR is allowed (e.g. you're using an inhouse developed application with continuous integration and serveradmins are in the same line, etc), then you could also use a <context-param> in web.xml instead.

<context-param>
    <param-name>config.location<param-name>
    <param-value>/path/to/file</param-value>
</context-param>

It's then in any Servlet (or better, ServletContextListener) available by ServletContext#getInitParameter():

String configLocation = servletContext.getInitParameter("config.location");
File configFile = new File(configLocation, "config.properties");
// ...

Answer 4

I just solved a similar problem in a slightly different way. Our customer wants to configure database connection details, integration server locations and ports etc. without rebuilding the war. Using environment property to point an external file containing the information may or may not be okay, but it felt a bit dirty trick. Anyway, here's a slightly more enterprisey way.

For database connections we use JNDI lookup and below is the current solution for integration server parametrization. The parameters can come from at least three different sources now:

1. properties-file, which is overridable with Maven profiles and requires single line of xml in spring configuration to be accessible. This is obviously inside the war file.
2. web.xml context-param. This is also, of course, inside the war file.
3. Tomcat server can override the init parameters with context.xml which can be outside the war. This happens to be the same file where JNDI context is defined, which is nice.

Below is the implementation for configuration accessor bean. It can run in servlet context and also without one (for some unit tests it makes little sense to kickstart a full-blown web server, but we nevertheless need to satisfy spring bean injections).

I don't mean this to be a perfect solution, but it is one. Didn't find anything like this with google.

@Service
public class IntegrationConfigurationImpl implements
   IntegrationConfiguration, InitializingBean,
   ServletContextAware, ApplicationContextAware  {

private static final String SERVER_HOST_PROPERTY = "integration.server.host";
private static final String SERVER_PORT_PROPERTY = "integration.server.port";
private static final String PROPERTY_BEAN_NAME = "integrationProperties";

private ServletContext servletContext;
private ApplicationContext applicationContext;

private static final Logger log = LoggerFactory.getLogger(IntegrationConfigurationImpl.class);
private String serverHost = "foo";
private int serverPort  = 42;

@Override
public String getServerHost() {
    return serverHost;
}

@Override
public int getServerPort() {
    return serverPort;
}

@Override
public void setServletContext(ServletContext servletContext) {
    this.servletContext = servletContext;
}

@Override
public void setApplicationContext(ApplicationContext applicationContext) {
    this.applicationContext = applicationContext;
}

@Override
public void afterPropertiesSet() throws Exception {
    // konfiguraation validointi..
    if (servletContext == null) {
        log.info("servlet context not set, not running as a web application. Trying to get properties from application context");
        if (applicationContext.containsBean(PROPERTY_BEAN_NAME)) {
            Properties p = (Properties)applicationContext.getBean(PROPERTY_BEAN_NAME);
            serverHost = p.getProperty(SERVER_HOST_PROPERTY);
            serverPort = Integer.valueOf(p.getProperty(SERVER_PORT_PROPERTY)).intValue();
        } else {
            log.info("Property bean not found :" + PROPERTY_BEAN_NAME);
        }
    } else {
        serverHost = servletContext.getInitParameter(SERVER_HOST_PROPERTY);
        serverPort = Integer.valueOf(servletContext.getInitParameter(SERVER_PORT_PROPERTY)).intValue();
    }
    log.info("Using integration server " + getServerHost() + ", port " + getServerPort());
}

}

Answer 5

The disadvantage with having system property is you need to restart the container to modify the system parameter.

Having it as init-param in web.xml, can allow you to modify by just restarting the web app.

Having in init-param is a better way.