SpringBoot Pre Spring-boot 2.0 Relaxed Binding - Clarify whether previous 1.x relaxed behavior is possible

Using references:

https://spring.io/blog/2018/03/28/property-binding-in-spring-boot-2-0 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide#relaxed-binding

I am looking at the mention in the first URL reference above to IterableConfigurationPropertySource having been added and in the second URL reference of RelaxedPropertyResolver having been removed. The existing documentation around this is not clear as to whether the spring boot 2.x provided Interfaces can be used to achieve the spring boot 1.x behavior.

We have legacy use cases for allowing underscores in entity names (Configuration property names) which we load for our use with spring boot 1.x. The changes for Spring-boot 2.0 break our use. We really want it back. :-)

There is a strong case that developers know their data and if they want an implementation of configuration property names which works for them, even if they are not the current standard in vogue with the spring team, then Interfaces or environment settings should be provided to enable using teams to use new/latest code with old data.

An example of this was the change that the Apache Tomcat team made in in version 9.x in restricting the use of special characters in the URL. This change was done to make Tomcat more 'secure' as per RFC 7230 and RFC 3986. Even though this change was not adequately communicated by the Apache Tomcat team, they did provide a mechanism through an entry in server.xml for relaxedQueryChars.

This change to spring-boot 2.0 behavior around relaxed property behavior making a change that breaks existing implementations is very much like the Apache Tomcat case.

So I'm asking

Regardless of what the canonical/current standards are for configuration property names, can the spring boot 1.x behavior be achieved in spring boot 2.x using the existing Interfaces in spring boot 2.x (like a CustomRelaxedPropertyResolver OR a PropertyNameRegexMapper)?
If no, can someone outline a brief approach for end users to customize/rebuild/fork springboot to achieve this behavior.
Is spring boot 1.x still being maintained in support of CVE remediation, etc.
Are there published technical guidelines for the spring boot team (and/or larger spring team) that establishes the philosophy/guidelines to be used as the code evolves in order to reduce the amount of rework that teams using spring have to undergo as major functionality changes like this are made? The typical strategy in the Java world is to deprecate features and leave them around for a number of releases before removing them. This change in the property naming from spring boot 1.x to 2.x is abrupt and its impacts significant, especially for teams who are using spring cloud config and the spring boot mechanism as their standard across wide sets of applications/implementations.

Thanks!

Comment From: wilkinsona

Thanks for the report. Unfortunately, it's not clear to me what you're asking for. I've gathered that you're interested in configuration property binding behaviour and, I think, the treatment of - characters in particular. Beyond that, I'm unsure exactly what 1.5 behaviour you were relying up that isn't currently working for you in 2.x.

If you would like us to spend some more time trying to assist you, can you please take the time to provide a complete yet minimal sample that works with Spring Boot 1.5 and fails with 2.x. You can share such a sample with us by zipping it up and attaching it to this issue or by pushing it to a separate repository on GitHub.

Is spring boot 1.x still being maintained in support of CVE remediation, etc.

No, the 1.x line reached the end of its supported life in August 2019.

the philosophy/guidelines to be used as the code evolves in order to reduce the amount of rework that teams using spring have to undergo as major functionality changes like this are made

We only make major breaking changes in major releases. Minor releases may see some small breaking changes, but they should be easily adapted to. Maintenance releases should be drop-in replacements for the previous release.

Comment From: bodhi-one

Hi Wilkinsona, thanks for the quick reply

We have entries in our spring cloud config which do have underscores in the name like this one:

 "xyz_db": {
    "xyz_db_url": "jdbc:oracle:thin:@some-oracle-server:1521:ORCL",
  }

These are no longer allowed in spring-boot 2.x and have the following stack trace:

Caused by: org.springframework.boot.context.properties.source.InvalidConfigurationPropertyNameException: Configuration property name 'xyz_db' is not valid
   at org.springframework.boot.context.properties.source.ConfigurationPropertyName.elementsOf(ConfigurationPropertyName.java:565)
   at org.springframework.boot.context.properties.source.ConfigurationPropertyName.elementsOf(ConfigurationPropertyName.java:542)
   at org.springframework.boot.context.properties.source.ConfigurationPropertyName.of(ConfigurationPropertyName.java:533)
   at org.springframework.boot.context.properties.source.ConfigurationPropertyName.of(ConfigurationPropertyName.java:510)
   at org.springframework.boot.context.properties.bind.Binder.bind(Binder.java:225)
   at org.springframework.boot.context.properties.ConfigurationPropertiesBinder.bind(ConfigurationPropertiesBinder.java:90)
   at org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor.bind(ConfigurationPropertiesBindingPostProcessor.java:89)

We also have other entries that are Oracle schema names which is very common to have _ in the names

{
  "database": {
    "pools": {
      "SOME_SCHEMA_USER": {
        "driver-url": "jdbc:oracle:thin:@some-oracle-server:1521:ORCL",
        "driver-properties": {
          "password": "{SomeEncryptedPassword==}"
        },
        "maximum-connection-count": "10",
        "minimum-connection-count": "1"
      },

Comment From: wilkinsona

Thanks for the additional information but it's not really what I was looking for. Without knowing how you are attempting to bind things, it's going to be rather hard to help you. As I said above, if you would like us to spend some more time trying to assist you, can you please take the time to provide a complete yet minimal sample that works with Spring Boot 1.5 and fails with 2.x. You can share such a sample with us by zipping it up and attaching it to this issue or by pushing it to a separate repository on GitHub.

Comment From: bodhi-one

Hi, I spent a few hours trying to get a paired down example for you. I admit I am challenged to find a good git project to base it on as spring has evolved quite a bit in the past few years. Our code is segmented across a number of projects making it difficult to isolate a non-proprietary sample for you. I was starting as from this project https://github.com/himnay/spring-boot-config-client but ran into issues there as well.

I thought the provided information was enough. We did change from using like "xyz_db": { "xyz_db_url": "jdbc:oracle:thin:@some-oracle-server:1521:ORCL", }

to using like

"xyz-db": { "xyz_db_url": "jdbc:oracle:thin:@some-oracle-server:1521:ORCL", }

And we are able to get past this issue. If there was a simple override to preserve the old relaxed behavior that would have been ideal. Either way we can do this change in our config files.

Thanks again, closing this issue.

Comment From: bodhi-one

closing