Spring JavaConfig
  1. Spring JavaConfig
  2. SJC-16

PropertyPlaceholderConfigurer-like feature for java configurations

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.0 M1
    • Fix Version/s: None
    • Component/s: Public API
    • Labels:
      None

      Description

      As it is possible with PropertyPlaceholderConfigurer for xml configurations, it would be nice if there was some way to provide properties to java configurated beans.

      A proposition has been made with issue SJC-2 but I am not sure if using annotated method arguments is the right way to do it. Maybe. Do you already have a strategy for this?

      Anyways, I was thinking about it and maybe it could be done like this (see example below). Methods (or protected fields?) annotated with @Property could be implemented by the cglib-enhanced configuration class (like @AutoBean works) and return the property value. That would replace the property placeholders like $

      {some.property}

      in xml bean definitions. Then we would need something to tell Spring where our properties are defined. There could exist an annotation such as @PropertyConfigurer to place on @Bean methods to indicate that this bean provides properties to be injected for @Property annotated methods... or maybe there would be no need for the @Bean annotation... or maybe there is no need for any annotation at all: just detecting that the return type of the method implements some interface could be enough.

      ...just brainstorming...

      @Configuration
      public class SomeConfig {

      @Bean
      @PropertyConfigurer
      public ResourcePropertyConfigurer myProperties()

      { return new ResourcePropertyProvider("classpath*:META-INF/*.properties"); }

      }

      @Configuration
      public class SomeOtherConfig {

      // type conversion would occur here to parse the property as an integer
      @Property(name = "some.property", default="1")
      public abstract int someIntegerProperty();

      @Bean
      public SomeBean someBean()

      { return new SomeBean(someIntegerProperty()); }

      }

        Issue Links

          Activity

          Hide
          Michal Grosos added a comment -

          Here's how I am doing it. I guess, it's better to leave this kind of configuration in the XML file, but I was just too eager to configure my app absolutelly without an XML file

          private static String SETTINGS_PROPERTIES = "sk/seges/attis/config/dataSourceConfiguration.properties";
          private static final Properties settingsProperties;
          static {
          InputStream is = null;
          try

          { is = ClassLoader.getSystemClassLoader().getResourceAsStream(SETTINGS_PROPERTIES); settingsProperties = new Properties(); settingsProperties.load(is); }

          catch (Exception e)

          { throw new ExceptionInInitializerError(e); }

          finally {
          if(is != null) {
          try

          { is.close(); }

          catch (Exception e)

          { throw new ExceptionInInitializerError(e); }

          }
          }
          }

          @SuppressWarnings("unused")
          @Bean
          private DriverManagerDataSource dataSource()

          { DriverManagerDataSource dataSource = new DriverManagerDataSource(); dataSource.setUrl(settingsProperties.getProperty("db.url")); dataSource.setUsername(settingsProperties.getProperty("db.username")); dataSource.setPassword(settingsProperties.getProperty("db.userpassword")); dataSource.setDriverClassName(settingsProperties.getProperty("db.driver")); return dataSource; }

          In other words, when you give up the idea of configuring the class's properties using annotations, you can do pretty much you want, like implement your own PropertyPlaceholderConfigurer, since you are in java. IMO, the PropertyPlaceholderConfigurer makes sense only in XML configurations.

          Show
          Michal Grosos added a comment - Here's how I am doing it. I guess, it's better to leave this kind of configuration in the XML file, but I was just too eager to configure my app absolutelly without an XML file private static String SETTINGS_PROPERTIES = "sk/seges/attis/config/dataSourceConfiguration.properties"; private static final Properties settingsProperties; static { InputStream is = null; try { is = ClassLoader.getSystemClassLoader().getResourceAsStream(SETTINGS_PROPERTIES); settingsProperties = new Properties(); settingsProperties.load(is); } catch (Exception e) { throw new ExceptionInInitializerError(e); } finally { if(is != null) { try { is.close(); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } } } @SuppressWarnings("unused") @Bean private DriverManagerDataSource dataSource() { DriverManagerDataSource dataSource = new DriverManagerDataSource(); dataSource.setUrl(settingsProperties.getProperty("db.url")); dataSource.setUsername(settingsProperties.getProperty("db.username")); dataSource.setPassword(settingsProperties.getProperty("db.userpassword")); dataSource.setDriverClassName(settingsProperties.getProperty("db.driver")); return dataSource; } In other words, when you give up the idea of configuring the class's properties using annotations, you can do pretty much you want, like implement your own PropertyPlaceholderConfigurer, since you are in java. IMO, the PropertyPlaceholderConfigurer makes sense only in XML configurations.
          Hide
          Chris Beams added a comment -

          SJC-74 addresses property-placeholder-like functionality for JavaConfig

          Show
          Chris Beams added a comment - SJC-74 addresses property-placeholder-like functionality for JavaConfig
          Hide
          Chris Beams added a comment -

          As mentioned previously, SJC-74 covers this functionality. See comments there for details.

          Show
          Chris Beams added a comment - As mentioned previously, SJC-74 covers this functionality. See comments there for details.
          Hide
          Chris Beams added a comment -

          For those interested in this issue, please take a look at the @PropertiesValueSource / @ExternalValue support coming out shortly in 1.0.0.m4. It's stable in the nightlies as well.

          Show
          Chris Beams added a comment - For those interested in this issue, please take a look at the @PropertiesValueSource / @ExternalValue support coming out shortly in 1.0.0.m4. It's stable in the nightlies as well.
          Hide
          Chris Beams added a comment -

          Linking to SJC-166, the issue that introduced @PropertiesValueSource

          Show
          Chris Beams added a comment - Linking to SJC-166 , the issue that introduced @PropertiesValueSource

            People

            • Assignee:
              Chris Beams
              Reporter:
              Guillaume Duchesneau
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development