J2EE change management


General J2EE: J2EE change management

  1. J2EE change management (3 messages)

    I have a question that I sure has been answered a hundred times, I just see the solution clearly myself.

    At my company, several environments exist for our web application:

    Development - where new code is developed; volatile
    Test - where initial testing is done; somewhat stable
    Staging - where integration & load testing is done; stable
    Production - multiple boxes; stable

    My question is this...Ideally, we would deploy the same EAR in each environment. However, certain files that are specific to each environment exist that cannot be contained in the EAR file (log config files, etc).

    I have some ideas on how to overcome this. I just would like to see how of others addressed this.

    Threaded Messages (3)

  2. J2EE change management[ Go to top ]

    We use Ant and create different properties files for each configuration. These properties are mapped to filters and the config files are copied into our build directory using parameter substitution (e.g. @jsp.precompile@) and integrated into a war or ear from there.

    Our build.xml contains these definitions:

        <!-- setup build configuration -->
        <property name="config" value="dev" />
        <property file="build-${config}.properties" />
        <property file="build.properties" />

        <!-- define source directories -->
        <property name="conf.src.dir" value="${basedir}/conf"/>

        <!-- define build directories -->
        <property name="build.dir" value="${basedir}/build"/>
        <property name="conf.dir" value="${build.dir}/conf-${config}"/>

    The main build.properties defines the standard properties. The default config is "dev" (what the developers use all the time) so a build-dev.properties file contains the default overrides or additions to those properties, likewise a build-test.properties would contain the properties for the test environment. (the order may seem backwards but its important in ant)

    The files are copied from ./conf to build/conf-dev or build/conf-test, and the war task includes the files from whichever directory is appropriate.

    One other thing that's important to do is to set the ant "overwrite" target when your build properties change so that the config files are re-copied. The following is an excerpt from our "prepare" target.

        <!-- prepare conf dir by filtering defualt conf files -->
        <filter token="cactus.baseurl" value="${cactus.baseurl}"/>
        <filter token="jsp.option1.key" value="${jsp.option1.key}"/>
        <filter token="jsp.option1.val" value="${jsp.option1.val}"/>
        <filter token="jsp.option2.key" value="${jsp.option2.key}"/>
        <filter token="jsp.option2.val" value="${jsp.option2.val}"/>
        <filter token="jsp.option3.key" value="${jsp.option3.key}"/>
        <filter token="jsp.option3.val" value="${jsp.option3.val}"/>
        <filter token="config" value="${config}"/>
        <!-- set overwrite flag if one of the build files changed -->
        <condition property="overwrite.conf">
            <uptodate property="overwrite.conf" targetfile="${conf.dir}/.touch">
              <srcfiles dir= "${conf.src.dir}"/>
              <srcfiles dir= "${basedir}" includes="build.xml,build.properties"/>
              <srcfiles dir= "${basedir}" includes="build-${config}.properties"/>
        <copy toDir="${conf.dir}" filtering="true" overwrite="${overwrite.conf}">
          <fileset dir="${conf.src.dir}"/>
        <touch file="${conf.dir}/.touch"/>

    Anyway, I hope this is helpful for you. It works great for us.

    Tim Dawson
    Lead Technical Architect
    Notiva Corporation
  3. J2EE change management[ Go to top ]

    Whoops, I forgot to mention that in order to override the seemingly hardcoded config of "dev" you need to run ant with a command line option to set the property...

    ant <target> -Dconfig=test

    This overrides anything set inside the build.xml file. You can also add targets that do this for you, i.e. "ant buildtest" which sets config=test & calls its own build target. We do some of each (our autobuild uses a task that sets the config to "devauto" and calls several other targets. When we're doing a manual build we tend to use the command line.

  4. J2EE change management[ Go to top ]

    Thanks Tim. That is sort of the path we are, but you comments cast a little different light on it and gave me some new ideas.

    Ant ROCKS!!!