How to pass deployment dependant parameters to webapp

Question

In projects I work(ed) on, deployment parameters - such as storage path or DB login - are usually given through a parameter file, which is stored in the war file.

I find that unsuitable because those values needs to be changed each time the webapp is packaged for a different deployment (dev vs prod, change of executing computer). The source code being versioned, this makes it even more bothering.

Is there some better option to pass parameters such as listed above?

By better, I mean:

• practical: simple to setup, change and explain to others
• separated from the war
• as independent as possible to the web container (if dependent, I'm using tomcat in prod)

Edit

I chose the answer of @aksappy to reward the work done in the answer and because it provided several methods using standard tools. However, depending on the context I could go for any other solutions:

• method of @Necreaux has best simplicity
• method of @Luiggi Mendoza has a good design and is still simple
• method of @OldCurmudgeon would be a really good one if the code covered other cases.

Answer 1

You can use a multitude of things based on your environment. Here are somethings which may be considered

1. Use datasources The datasources defined in the server context removes the hard wired dependency of managing db configurations and connection pool from the web application. In Tomcat, this can be done as below in the context.xml

<Context>
       ...
      <Resource name="jdbc/EmployeeDB" auth="Container"
                 type="javax.sql.DataSource"
          description="Employees Database for HR Applications"/>
      </Context>

2. Use Contexts

You can configure named values that will be made visible to the web application as environment entry resources, by nesting entries inside this element. For example, you can create an environment entry like this: (Source here). This can be set as context parameters or environment entries. They are equivalent to the entries made in a web.xml or a properties file except that they are available from the server's context.

3. Use database configurations and load those configuration at ServletContextListener

Another approach which I tend to follow is to create a relational schema of properties in a database. Instead of loading the properties file during server startup, load the properties from the database during start up.

public class ContextInitialize implements ServletContextListener {
  private static Properties props;
  public void contextInitialized(ServletContextEvent servletContextEvent) {
     // connect to DB
     // Load all the key values pairs as required
     //put this into a Properties object, or create a hashtable, hashmap ..
  }
  //Getter
  public String getProperty(String key){
     // get value of key
  }
  //Setter
  public void setProperty(String key, String value){
     // set value to a key
  }
}

Note: above is just an example.

4. Use environment variables or classpath variables

Use classpath / path variables in Environment variables and use System.getenv() in your java code to get these values as necessary.

Answer 2

Two strategies I've used:

JVM Parameters -- Custom JVM parameters can be set by the container at startup. This can get a bit verbose though if you have a lot of settings.

Configuration Files -- These can be read by the application. Either the location is hardcoded, put inside the container path, or to get the best of both worlds, specify the location via a JVM parameter.

Answer 3

We normally put our web app properties files in the Tomcat home folder. POJOS look on the launch folder. There will be other standard locations for other web servers.

  final String tomcatHome = System.getProperty("catalina.home");
  if (tomcatHome == null) {
    // POJOs look in "."
    searchPaths.add(".");
  } else {
    searchPaths.add(tomcatHome);
    webApp = true;
  }

Answer 4

An strategy is to pack all the properties and configuration files in an external jar and make this jar a dependency for your application(s): war, ear, etc. Then, you can deploy this jar in a common folder where the application server will load it and make it available for all the applications deployed there. This means that you will deploy the jar with the values for each environment once (or every time you need to change it, but its changes must be slow compared to the changes made to your main artifacts) and you can deploy and redeploy your war or any other project in your application server without problems.

In case of Tomcat, you may deploy this jar inside %CATALINA_HOME%/lib as explained in Tomcat Tutorial. Class Loader Definitions

To consume (read) these files in my application, I just load them like any other resource in my application.