Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JOptCommandLinePropertySource selects property names in an inconsistent way [SPR-17639] #22168

Open
spring-projects-issues opened this issue Jan 4, 2019 · 3 comments · May be fixed by #22784
Open
Labels
in: core status: waiting-for-triage

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 4, 2019

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 7, 2019

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 7, 2019

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.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 7, 2019

Stéphane Nicoll commented

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

@spring-projects-issues spring-projects-issues added type: bug status: waiting-for-triage in: core and removed type: bug labels Jan 11, 2019
lgxbslgx added a commit to lgxbslgx/spring-framework that referenced this issue Apr 10, 2019
Only the longest name is used for enumerating.
If more than one name have the same longest length,
the first one(alphabetically) will be used.
Add the corresponding testcase.
Fix spring-projects#22168.
@lgxbslgx lgxbslgx linked a pull request Apr 10, 2019 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: waiting-for-triage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant