Details

    • Type: Enhancement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 2016.12.0
    • Component/s: None
    • Labels:
      None

      Description

      We've started having FooProperties, with string members to define the names of properties we care about. For instance

      public interface MessagingProperties {
        String REMOTE_HOST = "swarm.messaging.remote.host";
      }
      

      Which is great, but also difficult to keep up with default values, document, and more importantly, be able to display something helpful when a command-line user does --help.

      It might be nice, particularly now that we have CDI heartily in the mix, but possibly on the wrong side of the fence, to do something like:

      public class MessagingProperties {
        @Produces
        public static ConfigurationSpec REMOTE_HOST = new ConfigurationSpec("swarm.messaging.remote.host", "localhost");
      }
      

      CDI could then gather up all ConfigurationSpec to know what properties are actually active in a given combination of fractions. It could provide this information if someone does --help or perhaps through other tooling (project-stages.yml IDE auto-completion).

      The existing @ConfigurationValue could be modified to take, in addition to a String name as it current does, a ConfigurationSpec object when performing the lookup.

      That being said, I dunno if @Produces works on fields, or static fields, or whatnot. But some way to formalize the keys and default values (if any) that we actually support, instead of magic strings.

      It could also be beneficial if we could chain them, to avoid typos and repetition.

      public class FooProperties {
        public static ConfigurationSpec FOO = new ConfigurationSpec( "swarm.foo");
      
        @Produces
        public static ConfigurationSpec FOO_HOST = FOO.spec( "host", "localhost" );
      
        @Produces
        public static ConfigurationSpec FOO_PORT = FOO.spec( "port", 61616 );
      }
      

      Where ConfigurationSpec is akin to:

      public class ConfigurationSpec<T> {
        private String key;
        private T defaultValue;
      
        public ConfigurationSpec(String key) {
          this(key, null);
        }
      
        public ConfigurationSpec(String key, T defaultValue) {
          this.key = key;
          this.defaultValue = defaultValue;
        }
      
        public <T> ConfigurationSpec<T> spec(String subKey, T defaultValue) {
          return new ConfigurationSpec( this.key + '.' + subKey, defaultValue );
        }
      
        public String toString() {
          return this.key;
        }
      
        public Optional<T> defaultValue() {
          return Optional.of(this.defaultValue);
        }
      }
      

      Bonus points if somehow we can @Inject a sub-type of Optional<T> when doing our normal @ConfigurationValue injection, that automatically can accomodate the default value, enhancing on George Gastaldi's work.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                bob.mcwhirter Bob McWhirter
                Reporter:
                bob.mcwhirter Bob McWhirter
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: