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
/actuator/configprops
does not expose a property when second character is uppercase
#13878
Comments
I can confirm that the Can you please clarify what you mean by "misconfiguration (!)". I can see that the setter is called with the proper value once I've removed lombok from the picture (and I can add a debug point in the setter). The canonical name of that property is |
Thanks for the quick reply; You're right in that the correct value is indeed stored in the app class fields. I'd correlated not seeing them in configprops as cause of the issue we're having: a default value we set in |
That’s not how an environment variable should be formatted. Please review the documentation. Before opening a new issue, let's figure out what this one is about. If I turns out your project is working fine we can create a dedicated one for the |
Thanks for the hint on enviroment variable formatting; I'd looked towards the Relaxed Binding 2.0 Wiki page which reads:
I'd took that to mean as that any mixed case environment variable is lowercased and only then matched against From the documentation link you gave it seems I should uppercase all my environment properties, correct? If confirmed (tomorrow, for lack of access now) that would reduce this issue down to something along the lines of "actuator configprops fails to show properties where second character is uppercase"; a weird one, that sent me down the wrong path debugging what might still be a configuration migration issue on our part. |
Sorry for the delay in responding; it does appear as though the correct values are set, reducing this issue down to merely the properties shown in |
/actuator/configprops
does not expose a property when second character is uppercase
Thanks for the feedback @timtebeek |
So the bug/limitation is in the way we configure the As a result, There might be a limitation in Jackson as well, see this issue |
Hi! In migrating to Spring Boot 2 I came across a curious mismatch in our properties, illustrated in the following project & test: https://github.com/timtebeek/env-matching/blob/master/src/test/java/com/github/timtebeek/envmatching/EnvMatchingApplicationTests.java#L29
My application is nothing more than:
But when I run my simple JUnit test:
It fails on the final assertion. So
sample.someProp1
is matched perfectly fine, whereassample.oAuthProp2
is not matched. In our case this leads tomisconfiguration(!) andsome confusion. I've found the workaround to be to lowercase the property, but that's quite surprising to me. Can you enlighten me if I'm correct in having assumed this would work?I'm aware there were substantial changes to the relaxed binding in Spring Boot 2, but never expected the second character being uppercase to be a problem at all. An uppercase letter as third character also work fine, so really weird behavior here.
The text was updated successfully, but these errors were encountered: