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

@Configuration(prefix = "foo") on an interface, in conjunction with a parameterized @PropertyName fails #676

Closed
akang31 opened this issue Sep 25, 2023 · 0 comments · Fixed by #680
Assignees

Comments

@akang31
Copy link
Contributor

akang31 commented Sep 25, 2023

When applying @configuration(prefix = "foo") on an interface, we would expect that any @PropertyNames specified in the interface would automatically look for foo.[names], but this does not apply when there are parameters specified, instead using the PropertyName directly.

Example

@Configuration(prefix = "foo") 
interface BogusConfiguration {
  @DefaultValue("BAD")
  @PropertyName(name = "bar")
  String getFooBar();

  @DefaultValue("BAD")
  @PropertyName(name = "${0}")
  String getFoo(String bar);
}

Given config

foo.bar: "GOOD"
foo.baz: "ALSO GOOD"
bar: "ALSO BAD"

Expected

getFooBar() --> GOOD
getFoo("bar") --> GOOD
getFoo("baz") --> ALSO GOOD

Actual

getFooBar() --> GOOD
getFoo("bar") --> ALSO BAD
getFoo("baz") --> BAD // From the default value

Issue is in ConfigProxyFactory.createParameterizedProperty.

Changing this to only the correct behavior would be breaking for many clients, we will include backward compatibility for cases in which clients specify the prefix (e.g. in the above example, a name = "foo.${0}" would also produce the same result).

This would however still be breaking for clients that specified a prefix at the top level config, and then ignored it in the body.

@akang31 akang31 self-assigned this Sep 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant