Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      When creating beans such as a JNDITemplate it is often desireable to have a container supply the provider URL and other configuration options via Environment entries. I find it is generally not a great idea swap applicationContext files using a build script because it adds another layer of complexitity to the build process. Therefore I prefer having different deployment descriptors on different test/production servers with different Environment settings. The real benefit comes with the ability for certain containers to update these Environment entries during runtime such as if a provider URL becomes inaccessible. I propose a JNDI Property Placehold Configurer which will do java:comp/env/ lookups to fill in the appropriate property values.

      Example usage would be as follows:

      <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
      <constructor-arg index="0">
      <props>
      <prop key="java.naming.factory.initial">$

      {java.naming.factory.initial}

      </prop>
      <prop key="java.naming.provider.url">$

      {java.naming.provider.url}

      </prop>
      <prop key="java.naming.factory.url.pkgs">$

      {java.naming.factory.url.pkgs}

      </prop>
      </props>
      </constructor-arg>
      </bean>

      I will attach a working version I have been using for several months now.

        Issue Links

          Activity

          Hide
          nicolas de loof added a comment -

          nice contribution

          I'd suggest to implement InitializingBean to avoid the init-method="initialize"

          I'm using a combination of JndiAwarePropertyPlaceholderConfigurer + JndiPropertiesFactoryBean to use my JNDI env-entry as

          • configurable path for PlaceHolder locations
          • placeholder for other beans that require configurable path (typically, building commons-configuration bean) :
            <bean
              class="org.springframework.beans.factory.config.JndiAwarePropertyPlaceholderConfigurer"
              init-method="initialize"
              p:systemPropertiesModeName="SYSTEM_PROPERTIES_MODE_OVERRIDE"
              p:jndiPropertiesModeName="SYSTEM_PROPERTIES_MODE_OVERRIDE"
              p:ignoreResourceNotFound="true">
              <property name="locations">
                <list>
                  <value>classpath:default.properties</value>
                  <value>file:///${app.home}/local.properties
                  </value>
                </list>
              </property>
              <property name="properties">
                <bean class="org.springframework.jndi.JndiPropertiesFactoryBean" />
              </property>
            </bean>
             
            <bean id="configuration"
              class="org.apache.commons.configuration.CompositeConfiguration">
              <constructor-arg type="java.util.Collection">
                <list>
                  <bean class="org.apache.commons.configuration.PropertiesConfiguration">
                    <constructor-arg type="java.net.URL" value="file:///${app.home}/local.properties"/>
                  </bean>
                </list>
              </constructor-arg>    
            </bean>
          
          Show
          nicolas de loof added a comment - nice contribution I'd suggest to implement InitializingBean to avoid the init-method="initialize" I'm using a combination of JndiAwarePropertyPlaceholderConfigurer + JndiPropertiesFactoryBean to use my JNDI env-entry as configurable path for PlaceHolder locations placeholder for other beans that require configurable path (typically, building commons-configuration bean) : <bean class= "org.springframework.beans.factory.config.JndiAwarePropertyPlaceholderConfigurer" init-method= "initialize" p:systemPropertiesModeName= "SYSTEM_PROPERTIES_MODE_OVERRIDE" p:jndiPropertiesModeName= "SYSTEM_PROPERTIES_MODE_OVERRIDE" p:ignoreResourceNotFound= "true" > <property name= "locations" > <list> <value> classpath:default.properties </value> <value> file:///${app.home}/local.properties </value> </list> </property> <property name= "properties" > <bean class= "org.springframework.jndi.JndiPropertiesFactoryBean" /> </property> </bean> <bean id= "configuration" class= "org.apache.commons.configuration.CompositeConfiguration" > <constructor-arg type= "java.util.Collection" > <list> <bean class= "org.apache.commons.configuration.PropertiesConfiguration" > <constructor-arg type= "java.net.URL" value= "file:///${app.home}/local.properties" /> </bean> </list> </constructor-arg> </bean>
          Hide
          Stephane Toussaint added a comment -

          I work slightly differently on my projects :
          I don't expect my customer to update for instance the Tomcat Context.xml in order to add a new Environment entry in order to add/override placeHolder values.
          Instead, I add in the very same context an entry which provides the path to a properties file :

          <Context ...>
              ...
              <Environment type="java.lang.String" name="my.properties" value="/.../user.properties"/>
              ...
          </Context>
          

          Then I implements a JndiResourceResolver which does the lookup and return the Resource

          <bean class="my.JndiResourceResolver">
              <property name="jndiName" value="java:comp/env/my.properties"/>
          </bean>
          

          AFAIC, I'd like to have something like this directly integrated by Spring. A sort of

          <context:property-placeholder location="classpath:default.properties, jndi-java:comp/env/my.properties" />
          

          Maybe it is another way to achieve what this issue expects ?

          Show
          Stephane Toussaint added a comment - I work slightly differently on my projects : I don't expect my customer to update for instance the Tomcat Context.xml in order to add a new Environment entry in order to add/override placeHolder values. Instead, I add in the very same context an entry which provides the path to a properties file : <Context ...> ... <Environment type= "java.lang.String" name= "my.properties" value= "/.../user.properties" /> ... </Context> Then I implements a JndiResourceResolver which does the lookup and return the Resource <bean class= "my.JndiResourceResolver" > <property name= "jndiName" value= "java:comp/env/my.properties" /> </bean> AFAIC, I'd like to have something like this directly integrated by Spring. A sort of <context:property-placeholder location= "classpath:default.properties, jndi-java:comp/env/my.properties" /> Maybe it is another way to achieve what this issue expects ?
          Hide
          Yuri Ch added a comment -

          Try this solution. It works for me:

          <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
          <property name="ignoreUnresolvablePlaceholders" value="true"/>
          <property name="ignoreResourceNotFound" value="true"/>
          <property name="locations">
          <list>
          <value>classpath:file_a.properties</value>
          <value>classpath:file_b.properties</value>
          <bean class="org.springframework.core.io.FileSystemResource">
          <constructor-arg>
          <bean class="org.springframework.jndi.JndiObjectFactoryBean">
          <property name="jndiName" value="java:comp/env/JndiPropertyNameReferringToTheFileLocation" />
          <property name="resourceRef" value="false" />
          <property name="defaultObject" value="/default/file/location" />
          </bean>
          </constructor-arg>
          </bean>
          </list>
          </property>
          </bean>

          .... and JNDI context ...
          <Environment description="Environment specific property"
          name="JndiPropertyNameReferringToTheFileLocation"
          type="java.lang.String"
          value="/etc/my-application/config.properties"/>

          voila!

          Show
          Yuri Ch added a comment - Try this solution. It works for me: <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="ignoreUnresolvablePlaceholders" value="true"/> <property name="ignoreResourceNotFound" value="true"/> <property name="locations"> <list> <value>classpath:file_a.properties</value> <value>classpath:file_b.properties</value> <bean class="org.springframework.core.io.FileSystemResource"> <constructor-arg> <bean class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/JndiPropertyNameReferringToTheFileLocation" /> <property name="resourceRef" value="false" /> <property name="defaultObject" value="/default/file/location" /> </bean> </constructor-arg> </bean> </list> </property> </bean> .... and JNDI context ... <Environment description="Environment specific property" name="JndiPropertyNameReferringToTheFileLocation" type="java.lang.String" value="/etc/my-application/config.properties"/> voila!
          Hide
          Chris Beams added a comment -

          Much of the functionality described by this issue should be handled by the new PropertySource abstraction released with Spring 3.1 M1. In particular, I'd like to hear feedback from those still interested in this issue about JndiPropertySource. It is an initial and basic implementation right now; I'd like to hear exactly what folks need to round it out.

          For an introduction to the new property management mechanism, take a look at http://blog.springsource.com/2011/02/15/spring-3-1-m1-unified-property-management. Feel free to comment here; I'll leave the issue open until we release 3.1 M2 (probably a few weeks from now).

          Show
          Chris Beams added a comment - Much of the functionality described by this issue should be handled by the new PropertySource abstraction released with Spring 3.1 M1. In particular, I'd like to hear feedback from those still interested in this issue about JndiPropertySource . It is an initial and basic implementation right now; I'd like to hear exactly what folks need to round it out. For an introduction to the new property management mechanism, take a look at http://blog.springsource.com/2011/02/15/spring-3-1-m1-unified-property-management . Feel free to comment here; I'll leave the issue open until we release 3.1 M2 (probably a few weeks from now).
          Hide
          Chris Beams added a comment -

          Resolving as Won't Fix - superseded by functionality in JndiPropertySource and PropertySourcesPlaceholderConfigurer

          Show
          Chris Beams added a comment - Resolving as Won't Fix - superseded by functionality in JndiPropertySource and PropertySourcesPlaceholderConfigurer

            People

            • Assignee:
              Chris Beams
              Reporter:
              Arthur
              Last updater:
              Trevor Marshall
            • Votes:
              10 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 51 weeks, 1 day ago