Spring JavaConfig
  1. Spring JavaConfig
  2. SJC-171

@PropertiesValueSource should search environment with precedence by default

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Public API
    • Labels:
      None

      Description

      Much like PropertyPlaceholderConfigurer, @PropertiesValueSource should, by default search the environment to see if any properties have been overridden with a -D flag.

      Implementing this is easy - delegate to the same internals that @EnvironmentVariableSource uses.

      This functionality should be on by default, but optionally disabled:

      @PropertiesValueSource(searchEnv=false)

        Issue Links

          Activity

          Hide
          Greg Turnquist added a comment -

          I have a current Spring app with the following in my appContext.xml:
          <bean id="properties" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
          <property name="locations">
          <list>
          <value>classpath:MyApp_$

          {context}

          .props</value>
          <value>classpath:Common.props</value>
          </list>
          </property>
          <property name="systemPropertiesModeName">
          <value>SYSTEM_PROPERTIES_MODE_OVERRIDE</value>
          </property>
          </bean>

          The idea is that the app is run like:
          java -Dcontext=dev myapp.jar
          or
          java -Dcontext=test myapp.jar
          or
          java -Dcontext=production myapp.jar

          with the understanding that properties shared between these environments is in Common.props, and properties distinct are in MyApp_dev.props, MyApp_test.props, and MyApp_production.props. With this feature added, I would definitely consider migrating to pure Java configuration.

          Show
          Greg Turnquist added a comment - I have a current Spring app with the following in my appContext.xml: <bean id="properties" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>classpath:MyApp_$ {context} .props</value> <value>classpath:Common.props</value> </list> </property> <property name="systemPropertiesModeName"> <value>SYSTEM_PROPERTIES_MODE_OVERRIDE</value> </property> </bean> The idea is that the app is run like: java -Dcontext=dev myapp.jar or java -Dcontext=test myapp.jar or java -Dcontext=production myapp.jar with the understanding that properties shared between these environments is in Common.props, and properties distinct are in MyApp_dev.props, MyApp_test.props, and MyApp_production.props. With this feature added, I would definitely consider migrating to pure Java configuration.
          Hide
          Chris Beams added a comment -

          Greg - this request will certainly be considered as this feature gets implemented. Thanks!

          Show
          Chris Beams added a comment - Greg - this request will certainly be considered as this feature gets implemented. Thanks!
          Hide
          Chris Mayes added a comment -

          Here's a patch that adds the Java system properties and environment handling logic from PropertyPlaceholderConfigurer to JavaConfig.

          Show
          Chris Mayes added a comment - Here's a patch that adds the Java system properties and environment handling logic from PropertyPlaceholderConfigurer to JavaConfig.
          Hide
          Chris Beams added a comment -

          Thanks, Chris. I'll review shortly. Be sure to add yourself as a watcher on this issue to be informed of updates.

          Show
          Chris Beams added a comment - Thanks, Chris. I'll review shortly. Be sure to add yourself as a watcher on this issue to be informed of updates.
          Hide
          Jacques Morel added a comment -

          Chris, this is a major barrier to our adoption of javaconfig in our application. We use a similar mechanism as Greg's and could not migrate to javaconfig until this is implemented.
          Any status on this? Will it be in 1.0.0?
          Thanks

          Show
          Jacques Morel added a comment - Chris, this is a major barrier to our adoption of javaconfig in our application. We use a similar mechanism as Greg's and could not migrate to javaconfig until this is implemented. Any status on this? Will it be in 1.0.0? Thanks
          Hide
          Chris Beams added a comment -

          Bulk closure of all outstanding SJC issues. If you are the reporter or a watcher of this issue, please note that JavaConfig functionality has been migrated to the core Spring Framework as of version 3.0.

          For details on what is currently supported in Spring 3.0, please see the documentation:

          http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

          If you believe this issue still applies to the @Configuration class support in Spring 3.0, please search for similar issues in the SPR project. If you cannot find what you're looking for, please do open a new issue. In the description, please mention this (SJC) issue so as to preserve history.

          Show
          Chris Beams added a comment - Bulk closure of all outstanding SJC issues. If you are the reporter or a watcher of this issue, please note that JavaConfig functionality has been migrated to the core Spring Framework as of version 3.0. For details on what is currently supported in Spring 3.0, please see the documentation: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java If you believe this issue still applies to the @Configuration class support in Spring 3.0, please search for similar issues in the SPR project. If you cannot find what you're looking for, please do open a new issue. In the description, please mention this (SJC) issue so as to preserve history.

            People

            • Assignee:
              Chris Beams
              Reporter:
              Chris Beams
            • Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development