3 Replies Latest reply on Apr 6, 2004 2:29 AM by Lennart Petersson

    Deployment to multiple environments

    mvitale Newbie

      Hello, all. I have an EJB application that's packaged up in an EAR file that I'm deploying to JBoss 3.2.3 on Linux using Sun's 1.4.1_07 JVM. I have a parameter that used to be in my web.xml file that I now need changed across my three environments (dev, tst, and prod.)

      The NetOps guys want a single .ear file that can be used cross-environments so they don't have to rebuild for production (and so we use the guaranteed-tested code in production from the test environment.)

      I've been looking through the jboss docs for a way to do this...I know that we already do something similar to this for our Datasource configuration through the appname-ds.xml file installed in $JBOSS/server/default/deploy. I just can't find anything pointing me to how to do this for a non-datasource parameter.

      The entry inside my web.xml file used to be:

      <context-param>
       <param-name>AppnameReports</param-name>
       <param-value>http://reports.in.mycompany.com/servlet/jrserver</param-value>
       </context-param>


      We've thought about moving this to a .properties file, but that would still require a rebuild for each environment. I've gotten this working through ant's build.xml file for each environment, but again, that requires a rebuild on a per-environment basis.

      Isn't there some form of XML file I can create and toss into each machine's $JBOSS/server/default/deploy directory (similar to appname-ds.xml) to configure that parameter?

      TIA,
      mvitale

        • 1. Re: Deployment to multiple environments
          jae Master

          you're just scratching the surface at what could be a larger can of worms b/c what are you going to do as soon as you have multiple files that need to change per environment, or you start including ejbs that need to have their deployment descriptors tweaked per environment.

          i just completed re-writing our entire build process and i opted to just redo the build each time we switch environments.

          if any of your code is dependent upon the values that change per environment, then the statement about "guarenteed-tested" code is no longer applicable b/c the code may work w/ the "test" value, but may not work w/ the "production" value.

          i'm also curious to see how others have overcome this issue, since i'm told the "rebuild" solution breaks configuration management best practices.

          • 2. Re: Deployment to multiple environments
            Juha Lindfors Master

            don't know about best practices but for testing I deploy the component multiple times with different configs and run test suites against each deployment

            for packaging I use a target per target environment

            • 3. Re: Deployment to multiple environments
              Lennart Petersson Novice

              Would it be possible to use a regular java system property instead that could be initiated using your run.sh/tbat

              <context-param>
              <param-name>AppnameReports</param-name>
              <param-value>${url.to.app}</param-value>
              </context-param>

              I'm not sure if it works in web.xml though....

              /L