Add support for configuration property fallback

[philwebb]

Some way to specify the default value for interfaces and a different fallback property.

[snicoll]

An example

@ConfigurationProperties("foo.bar")
public class BarProperties {

    private int timeout 1000;

    @ConfigurationPropertyValue(fallback = "foo.default.timeout")
    public int getTimeout() { return timeout; }
  
   public void setTimeout(int timeout) { ... }  

}

The same annotation can be used to provide default values for interface-based configuration properties, something like

@ConfigurationProperties("foo.bar")
public interface BarProperties {

    @ConfigurationPropertyValue(fallback = "foo.default.timeout", default = "1000")
    int getTimeout();

}

[afranken]

instead of (or in addition to) adding an annotation that works for interfaces for properties classes, you should add an annotation for fields of properties classes (much like the @Autowired annotation) and not force users to add public getter and setter methods to properties classes.

[wilkinsona]

@afranken Please see #1254

[thombergs]

In addition to defining a fallback, I would like to define whether it's allowed for a configuration property to be missing. Most of the times, startup of the application should fail when an expected property is missing. With @ConfigurationProperties alone, I currently see no possibility to fail on startup if a property is missing (other than creating a @PostConstruct method or something similar that does manual validation). It will just be assigned NULL or if it's a primitive the default value of that primitive type.

So, essentially, it would be great to be able to define exceptionIfMissing (in the style of exceptionIfInvalid on @ConfigurationProperties) on the annotation proposed by @snicoll like this:

@ConfigurationProperties("foo.bar")
public class BarProperties {

   private int optionalTimeout;
   private int mandatoryTimeout;

   @ConfigurationPropertyValue(exceptionIfMissing=false)
   public int getOptionalTimeout() { return optionalTimeout; }
  
   @ConfigurationPropertyValue(exceptionIfMissing=true)
   public int getMandatoryTimeout() { return mandatoryTimeout; }
  
  ...
}

What are your thoughts on this?

[afranken]

@thombergs I would expect that JSR-303 validation will keep working as it does right now:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-validation

In your example, you would annotate your Integer fields with for example @Max or @Min, and @NotNull if you wanted an exception to be thrown during startup...

[thombergs]

Ah, I didn't read the docs careful enough. Bean Validation works fine for my proposed use case. Thanks for the pointer.

[snicoll]

I gave this feature a bit more thought and it looks like we could use a clear split between two completely different features:

1. Offering a fallback mechanism
2. Allow a default value if no field is available (typically if/when we support interface binding).

Let's focus on 1. It feels to me the #1 use case is an object that gathers some default and then some Map of “stuff” with fallback on those defaults. As we aren't generating metadata for maps that fallback information will not end up in the metadata. I think that can be a problem.

Also if the fallback key has a fallback on its own you can easily create a cycle. It would be wise to allows only one level of fallback but given the metadata generation is completely decentralized, there is no way to prevent that to happen.

I am rephrasing the scope of this issue to be 1.

[ammmze]

This is thread is pretty old now, but would it be better to have @ConfigurationPropertyValue take an expression? Such as:

@ConfigurationProperties("foo.bar")
public interface BarProperties {

    @ConfigurationPropertyValue(default = "${foo.default.timeout:1000}")
    int getTimeout();

}

[philwebb]

We're going to be looking at immutable configuration properties so I think it's best to close this for now so we don't make that work more complicated. Once we've got immutable support in we can reconsider.