Announcement Announcement Module
Collapse
No announcement yet.
where is it recommended to put environment-specific application properties? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • where is it recommended to put environment-specific application properties?

    I wish to have my webapp as independent as possible from the environment properties such that if I redeploy a new version the existent property file (containing database URLs etc.) remains untouched (it is the responsibility of the deployment people as such). Putting the property file in the WEB-INF/classes is not a good idea since it is part of the hierarchy of the war file.

    Where is it recommended to put such properties? Is there a standard directory structure where you should put such property files (per webapp)?
    What is the recommended Spring property loader for this?

    I am using tomcat 6 to host my application.

  • #2
    In my experience it is rather rare for you to deploy new runtime properties for an application with no software changes. If you want them to be COMPLETELY decoupled, you might need to load them from a database (of course, to reload them, you'd still have to restart the application).

    Our solution until recently was to put our runtime properties in a separate jar file from our WAR and deploy the runtime properties JAR with the application WAR. This works great in JBOSS where you can drop a JAR file in the deploy folder and jboss will load it. Other containers (tomcat, glassfish, spring dm server) this doesn't work so well. You typically have to put these kinds of jar artifacts in a lib directory which means that you can't dynamically deploy them; you have to restart the server to pick up new jars.

    We abandoned that approach and now ALL of our runtime property files are packaged in the WAR and the appropriate file is selected at runtime by injecting a property into the container.

    I've blogged about this recently:

    My blog

    Comment


    • #3
      application assembly configuraton vs environment configuration

      Well, if the web application is not decoupled from the environment configuration it will be a bit of a headache for the deployment guys to maintain it in a proper way.

      Lets say they want to change the database URL, or some other configuration property which is not part of the assembly/deployment but purely something which is environment dependent. What I wish to check is if there is a standard or commonly used way of putting a separate property file somewhere else in the hierarchy, which is not under WEB-INF and not part of the war file.

      I encountered this blog, however this example goes to the extreme of putting it in the home directory, which is not ideal.

      http: simplericity.com/2007/09/18/1190139992626.html

      Comment


      • #4
        If you want EVERYTHING to be environment controlled, just pass all these properties through as system properties. Then NONE of them are deployed with your app. Spring's propertyplaceholderconfigurer will read system properties as well.

        With Jboss, you can pass in a property file for jboss to load in as env properties using the -P flag (e.g. -P ~/myproperties.properties).

        You could also have the properties deployed in JNDI; spring can then read from them. A former coworker of mine discusses that approach here:

        http://forum.springframework.org/showthread.php?t=31598

        See the post by TimMorrow at the bottom of the thread.

        Comment


        • #5
          Well putting everything as system properties is a bit extreme and unmanageable. I do not wish to go into customising the container startup scripts either because I see that a bit messy.

          What I was actually thinking of is a standard folder, which is still relative to the container, but external to the web application (so that it is not part of the war file). Just like it is standard to put classes in WEB-INF/classes, libraries in WEB-INF/lib, JPA configuration in META-INF/ etc.

          Maybe some /conf directory somewhere, however it has to be organised per webapp in some way.

          The JNDI approach is interesting.

          Comment

          Working...
          X