You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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...
Activity
snicoll commentedon Jan 13, 2017
An example
The same annotation can be used to provide default values for interface-based configuration properties, something like
afranken commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
@afranken Please see #1254
thombergs commentedon Feb 19, 2017
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 ofexceptionIfInvalid
on@ConfigurationProperties
) on the annotation proposed by @snicoll like this:What are your thoughts on this?
afranken commentedon Feb 19, 2017
@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 commentedon Feb 19, 2017
Ah, I didn't read the docs careful enough. Bean Validation works fine for my proposed use case. Thanks for the pointer.
35 remaining items