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
Currently, the value of the environment variable is not bound correctly. However, if I set the property in application.yml it does.
---
github:
client:
id: dummy-id
The weird thing is that the value that is bound is the value from the environment not from the application.yml file. I believe I've traced the bug to the RelaxedDataBinder.getProperyValuesForNamePrefix() method. The method attempts to find the candidate keys for bind, but does so by scanning for methods staring with <name>.. In my case it's looking for github. which doesn't exist until I create that key in the application.yml.
Once it's found the candidate key though, it seems to do the "relaxed" binding just fine.
I believe that a change needs to be made to use the "relaxed" key matching algorithm when searching for the candidate keys.
The text was updated successfully, but these errors were encountered:
RelaxedDataBinder now supports "env var" style variables that include the
path prefix, e.g. FOO_BAR_BAZ=boom will bind to a bean with property "baz"
and a binder with prefix "foo.bar".
Fixesspring-projectsgh-98
I'm attempting to map the value of the environment variable
GITHUB_CLIENT_ID
onto an@ConfigurationProperties
class as defined below:Currently, the value of the environment variable is not bound correctly. However, if I set the property in
application.yml
it does.The weird thing is that the value that is bound is the value from the environment not from the
application.yml
file. I believe I've traced the bug to theRelaxedDataBinder.getProperyValuesForNamePrefix()
method. The method attempts to find the candidate keys for bind, but does so by scanning for methods staring with<name>.
. In my case it's looking forgithub.
which doesn't exist until I create that key in theapplication.yml
.Once it's found the candidate key though, it seems to do the "relaxed" binding just fine.
I believe that a change needs to be made to use the "relaxed" key matching algorithm when searching for the candidate keys.
The text was updated successfully, but these errors were encountered: