chludwig-haufe opened SPR-17639 and commented

I recently had to build a Spring Boot command line application whose application context depends on command line options. I specified the qualified property names (i.e., "<prefix>.<prop-name>" as option alias names using the OptionParser#addAll(List<String>) method of JOpt's fluent interface. I injected a customized StandardEnvironment with a JOptCommandLinePropertySource based on the parsed command line arguments into the SpringApplication. To my surprise, however, some of the properties were never bound to the corresponding @ConfigurationProperties object.

I found that this was caused by the implementation of JOptCommandLinePropertySource#getPropertyNames(): A comment in the source code claims "only the longest name is used for enumerating". However, the implementation always returns the last element of OptionSpec#options(). This is, in general, not the longest option name, because OptionSpec#options() * first clusters the option names into short and long options and * then sorts these groups lexicographically, respectively.

For some options, JOptCommandLinePropertySource#getPropertyNames() therefore contained the qualified alias name required for binding the property to the @ConfigurationProperties object, while for other options it contained the unqualified option alias. Admittedly, the documentation of JOptCommandLinePropertySource never specifies which property names are enumerated; but I can't see a scenario where the current behavior is useful.

This ticket's reference URL points to a JUnit class that demonstrates this behavior. The test class also includes alternative property name selection strategies that would work better in my scenario. (I wonder why JOptCommandLinePropertySource#getPropertyNames() needs to filter the option alias names in the first place.)

Affects: 5.0.11, 5.1.3, 5.1.4

Reference URL: https://github.com/chludwig-haufe/JOptCommandLinePropertySource-Issues/blob/master/src/test/java/com/haufe/bugreports/spring/wrongpropertynamedemo/JOptCommandLinePropertySourceTests.java

Comment From: spring-projects-issues

Stéphane Nicoll commented

Thanks for the report but this issue tracker does not manage Spring Boot issues at all. Spring Boot has its own issue tracker: https://github.com/spring-projects/spring-boot

Comment From: spring-projects-issues

chludwig-haufe commented

Hu? AFAIK, JOptCommandLinePropertySource is a class of Spring Framework, not Spring Boot. I don't think the Spring Boot authors could do anything about it.

Comment From: spring-projects-issues

Stéphane Nicoll commented

Apologizes, I mixed up with our support in spring-boot-cli.

Comment From: snicoll

Unfortunately, we have to enumerate one property for each option. There's some discussion on the related PR and I've just clarified the expectations in 4b9f891. Binding to configuration properties require a set of stable options based on the enumeration, and configuring the option as described in the (now updated) doc should work.