Spring Roo
  1. Spring Roo
  2. ROO-629

Support different configurations for different environments (production, test, development)

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0.0.RELEASE, 1.0.1.RELEASE
    • Fix Version/s: None
    • Component/s: @ CORE
    • Labels:
      None

      Description

      Settings for production isn't always ideal for development, and vice versa. When switching environments (say from development to production), we have to change existing configurations to make the application run optimal. These settings include, but are not limited to

      • Logging
      • Caching
      • Database
      • Timezone
      • Exception Handling
      • Error Pages
      • Email Settings
      • Locale
      • Path where JNI binaries (DEBUG vs RELEASE) could be found, if any

      Have ROO generate applications that will load different settings based on the environment its running in. An "environment" could really be anything, but its suggested that ROO supports

      • production - deployed in a production environment
      • test - when unit tests are running during development or build
      • development - set during development

      Ruby on Rails uses the RAILS_ENV environment variable to determine the "environment" it runs under. ROO Applications can do the same. Just, don't use ROO_ENV, but rather use SAMPLE_ENV where SAMPLE is the ROO application name. This will allow for different applications to be deployed to different environments on the same OS. Ensure that when running tests, the environment is correctly set and that when running under development (mvn tomcat:run). If the environment is not specified, use production. Verify that the logs clearly indicated which "environment" the application is running under.

      When generating a brand new project, make sure there is a directory for each environment with the corresponding configuration files. Upon startup, load the correct configuration files based on the environment. To create a new environment, simply duplicate another environment, set the environment variable to the new environment and restart the application [unless the app can restart itself].

        Issue Links

          Activity

          Hide
          Dan Tanner added a comment -

          I agree about the need for supporting multiple environment configurations. Seems like a framework requirement for being production-ready. The rails style would work fine, or probably even more congruent would be to use the Grails style.

          Show
          Dan Tanner added a comment - I agree about the need for supporting multiple environment configurations. Seems like a framework requirement for being production-ready. The rails style would work fine, or probably even more congruent would be to use the Grails style.

          From gvNIX project (http://www.gvpontis.gva.es/cast/gvnix), we have developed an addon with this functionality.

          A commands list summary is as follows:

          • configuration save: Create a new configuration with a name
          • configuration activate: Update project files with the configuration property values
          • configuration unactivate: Unlink the project files from the active configuration
          • configuration list: List all previously saved configurations
          • configuration delete: Remove a previously saved configuration
          • configuration property list: Show the properties stored in a configuration
          • configuration property values: Show distinct property values along configurations
          • configuration property update: Set a value in a configuration property
          • configuration property add: Make available a property in the configurations
          • configuration property delete: Remove a property from all configurations

          Project files currently managed by configurations are:

          • Properties
          • src/main/resources/META-INF/spring/database.properties
          • src/main/resources/log4j.properties
          • Java
          • Java annotation attributes of a particular gvNIX project annotation
          • Xml
          • pom.xml
          • src/main/resources/META-INF/persistence.xml
          • src/main/resources/META-INF/spring/applicationContext.xml
          • src/main/webapp/WEB-INF/urlrewrite.xml
          • src/main/webapp/WEB-INF/web.xml
          • src/main/webapp/WEB-INF/spring/webmvc-config.xml

          You can add new project files to be managed by configurations.

          Show
          Mario Martínez Sánchez - gvNIX - DiSiD Technologies S.L. added a comment - From gvNIX project ( http://www.gvpontis.gva.es/cast/gvnix ), we have developed an addon with this functionality. A commands list summary is as follows: configuration save: Create a new configuration with a name configuration activate: Update project files with the configuration property values configuration unactivate: Unlink the project files from the active configuration configuration list: List all previously saved configurations configuration delete: Remove a previously saved configuration configuration property list: Show the properties stored in a configuration configuration property values: Show distinct property values along configurations configuration property update: Set a value in a configuration property configuration property add: Make available a property in the configurations configuration property delete: Remove a property from all configurations Project files currently managed by configurations are: Properties src/main/resources/META-INF/spring/database.properties src/main/resources/log4j.properties Java Java annotation attributes of a particular gvNIX project annotation Xml pom.xml src/main/resources/META-INF/persistence.xml src/main/resources/META-INF/spring/applicationContext.xml src/main/webapp/WEB-INF/urlrewrite.xml src/main/webapp/WEB-INF/web.xml src/main/webapp/WEB-INF/spring/webmvc-config.xml You can add new project files to be managed by configurations.
          Hide
          Stefan Schmidt added a comment -

          Mario, have you considered publishing these add-ons through RooBot so they get a little more exposure and community feedback? The documentation explaining how to publish addons through RooBot can be found here: http://static.springsource.org/spring-roo/reference/html-single/index.html#simple-addons

          -Stefan

          Show
          Stefan Schmidt added a comment - Mario, have you considered publishing these add-ons through RooBot so they get a little more exposure and community feedback? The documentation explaining how to publish addons through RooBot can be found here: http://static.springsource.org/spring-roo/reference/html-single/index.html#simple-addons -Stefan

          Hi Stefan !

          Yes, we want to publish gvNIX add-ons through RooBoot, but currently are only compatible with Roo 1.1.0.M1.
          We are working now on migration to Roo 1.1.0.M3 and next quarter we will migrate to latest stable Roo version.

          Show
          Mario Martínez Sánchez - gvNIX - DiSiD Technologies S.L. added a comment - Hi Stefan ! Yes, we want to publish gvNIX add-ons through RooBoot, but currently are only compatible with Roo 1.1.0.M1. We are working now on migration to Roo 1.1.0.M3 and next quarter we will migrate to latest stable Roo version.
          Hide
          Javier Beneito Barquero added a comment -

          I'm looking forward to find such configuration in Spring Roo.

          Show
          Javier Beneito Barquero added a comment - I'm looking forward to find such configuration in Spring Roo.
          Hide
          Enrique Ruiz (DiSiD) added a comment -

          gvNIX 0.7.0 includes dynamic configuration add-on. Release 0.8.0 will be able to export managed environment configuration to Maven profiles.

          Show
          Enrique Ruiz (DiSiD) added a comment - gvNIX 0.7.0 includes dynamic configuration add-on. Release 0.8.0 will be able to export managed environment configuration to Maven profiles.
          Hide
          Jesper Joergensen added a comment -

          Any chance Roo can use system-properties-mode="OVERRIDE" until this bigger feature is implemented. I think you will get a lot of mileage out of that simple change. With that, I can at least control the config that's already parametized in the various spring config files, such as database configuration. It would solve all problems, but it seems like a trivial change to me.

          Show
          Jesper Joergensen added a comment - Any chance Roo can use system-properties-mode="OVERRIDE" until this bigger feature is implemented. I think you will get a lot of mileage out of that simple change. With that, I can at least control the config that's already parametized in the various spring config files, such as database configuration. It would solve all problems, but it seems like a trivial change to me.
          Hide
          Saul Hazledine added a comment -

          I ended up at this issue after looking for a way to have different configurations for dev/production.

          I notice that this issue has a low priority and I am surprised by this as most production ready systems support different configurations. Is the low priority because there is a workaround? If so, what is the current way of supporting different configurations?

          Show
          Saul Hazledine added a comment - I ended up at this issue after looking for a way to have different configurations for dev/production. I notice that this issue has a low priority and I am surprised by this as most production ready systems support different configurations. Is the low priority because there is a workaround? If so, what is the current way of supporting different configurations?
          Hide
          Javier Beneito Barquero added a comment -

          Appart from the add-on mentioned by Mario above (Mario, have you published this add-on?), there is a workaround. It's not difficult, but maybe something annoying, because it requires manually editing some XML files and all the tests.

          First of all, you cannot remove some artifacts, like src/main/resources/META-INF/spring/applicationContext.xml, because Roo will regenerate them.

          The workaround that I've been using for a while is Spring profiles.

          For instance, datasources. Edit the applicationContex.xml and add a <beans profile="prod"> for defining a JNDI datasource, and a <beans profile="dev"> for a org.apache.commons.dbcp.BasicDataSource.

          It comes with a price to pay:
          · I have to add the active profile to the tests: @ActiveProfiles("dev")

          Because I don't want to include the database.properties to the production JAR, I like to move this file to src/test/resources/META-INF/spring/

          However, I've found that I have to edit the @ContextConfiguration annotation, that it's declared in the _Roo_IntegrationTest file, in order to use the classpath*:prefix in the locations attribute. Otherwise, the tests won't find the properties files that I've moved to the test resources path (with edit in the aj file, I mean push this annotation in the java file)

          See The classpath*: prefix

          It works very well for me, but from time to time I forget to edit the test files and I have to face unexpected Spring exceptions (for instance, the datasource cannot be injected)

          Show
          Javier Beneito Barquero added a comment - Appart from the add-on mentioned by Mario above (Mario, have you published this add-on?), there is a workaround. It's not difficult, but maybe something annoying, because it requires manually editing some XML files and all the tests. First of all, you cannot remove some artifacts, like src/main/resources/META-INF/spring/applicationContext.xml, because Roo will regenerate them. The workaround that I've been using for a while is Spring profiles. For instance, datasources. Edit the applicationContex.xml and add a <beans profile="prod"> for defining a JNDI datasource, and a <beans profile="dev"> for a org.apache.commons.dbcp.BasicDataSource. It comes with a price to pay: · I have to add the active profile to the tests: @ActiveProfiles("dev") Because I don't want to include the database.properties to the production JAR, I like to move this file to src/test/resources/META-INF/spring/ However, I've found that I have to edit the @ContextConfiguration annotation, that it's declared in the _Roo_IntegrationTest file, in order to use the classpath*:prefix in the locations attribute. Otherwise, the tests won't find the properties files that I've moved to the test resources path (with edit in the aj file, I mean push this annotation in the java file) See The classpath*: prefix It works very well for me, but from time to time I forget to edit the test files and I have to face unexpected Spring exceptions (for instance, the datasource cannot be injected)

            People

            • Assignee:
              Unassigned
              Reporter:
              Werner Strydom
            • Votes:
              61 Vote for this issue
              Watchers:
              46 Start watching this issue

              Dates

              • Created:
                Updated: