Announcement Announcement Module
Collapse
No announcement yet.
System configuration per environment Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I have a similar desire - I posted about it here: http://forum.springframework.org/showthread.php?t=46504
    "Conditional importing/loading of alternate beans.xml - environment specific beans"

    Basically I want to conditionally instantiate my JNDI beans dependant on environment - basically in test there's no JNDI. You can use <import> tags with ${} system properties, *but* I want it to default to a default import if the system property is not set.

    Comment


    • #17
      I've used a similar approach, but with a set of layered properties files, typically:

      common.properties -- generally stuff in here is common across all deployments
      ${environment}.properties -- dev, test, staging, production
      ${instance}.properties -- stuff specific to the unique deployed instance, if needed

      each file can override the ones above. I found this leads to easier configuration maintenance because a good deal of the stuff extracted into property configuration doesn't actually have to change among environments

      also, I try to avoid using properties to specify bean references or bean classes, as I've found that leads to pretty fragile configuration

      Comment


      • #18
        Originally posted by cfieber View Post
        I've used a similar approach, but with a set of layered properties files, typically:

        common.properties -- generally stuff in here is common across all deployments
        ${environment}.properties -- dev, test, staging, production
        ${instance}.properties -- stuff specific to the unique deployed instance, if needed

        each file can override the ones above. I found this leads to easier configuration maintenance because a good deal of the stuff extracted into property configuration doesn't actually have to change among environments

        also, I try to avoid using properties to specify bean references or bean classes, as I've found that leads to pretty fragile configuration
        This doesn't address my need to conditional instantiation of beans. I need to not instantiate a bean in one environment, and instantiate in another. It's can't be seperated into properties. (it's a bean looked up from jndi where JNDI doesn't exist in one of the environments i.e. jetty (i know you can setup jndi with jetty, but i don't want to have to)).

        Comment


        • #19
          Single Properties File Approach

          I've just posted an alternative approach, where all properties are contained in a single properties file here.

          Comment


          • #20
            Configleon

            I started a project that you may be interested in. It is called Configleon and solves the problem of loading property attributes in different environments and/or server contexts. With Configleon you can build one war file that can be deployed to every location.

            Configleon really shines is in its ability to cascade the property attributes. This allows all the common attributes to be defined in a global file and then overridden for each application server context.

            http://code.google.com/p/configleon/

            Comment


            • #21
              I don't think you guys get what I'm talking about. This is about different been combinations - not simply different properties. I.e a jndi datasource vs a non-jndi datasource. But this can be overcome by using mock jndi instances - which was most of the original problem I was having.

              Comment

              Working...
              X