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

Adopt spring-boot 2.x new and improved relaxed naming #331

Closed
kdvolder opened this issue Jul 24, 2019 · 2 comments
Closed

Adopt spring-boot 2.x new and improved relaxed naming #331

kdvolder opened this issue Jul 24, 2019 · 2 comments

Comments

@kdvolder
Copy link
Member

See: #327

Summary. Since spring-boot 2.0 relaxed name rules have become much more logical and well-defined which opens the door to us finally properly supporting this.

The rules are very well explained here:
https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0

Adopting the rules will mean re-thinking how we index and lookup property names.

I imagine we wouldn't index things based on the keys in the metadata (which contain hyphens) but rather based on the 'canonical' value of the key (lower case, all special chars removed).

Lookups should also use the canonical key. This means revisiting every place in the code that calls a lookup operation

  • ensure that canonical key is passed rather than the data found in the yaml file
  • make sure that caller is capable of dealing with discrepancies between the returned metadata items and their own (non-canonicalized version) of the key.
@kdvolder
Copy link
Member Author

kdvolder commented Dec 3, 2019

I finally got round again to taking a look a this. I've started reading and trying to really understand some of the materials around the new binding mechanics. On the wiki:

This has raised some questions for me. I've put these questions here:

spring-projects/spring-boot#17570

As that seemed to be an issue created specifically around providing assistance to implementing precise rules around the name binding.

I'm putting this issue back on hold for the time being as I don't think its a good idea to dive into this major refactoring until I got some answers.

@kdvolder
Copy link
Member Author

Doesn't make sense to invest a lot effort in this. It works well enough. If bugs are raised for specific problems we should address them specificially.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants