Consider how to support case sensitive key names with environment varaiables

[philwebb]

#17958 and #17975 shows how our current environment variable support suffers because it cannot deal with case sensitive values. The only current way to deal with these is by using the SPRING_APPLICATION_JSON variable.

It would be nice if we could find a way to support case sensitive key names.

[philwebb]

Since these are usually maps perhaps we need to find a way to push the key into the value. For example LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB_CONTEXT_CONTEXTLOADER=DEBUG is really adding an entry to the logging.level map. Perhaps LOGGING_LEVEL=org.springframework.web.context.ContextLoader:DEBUG?

[mlichtblau]

Hi, we bumped into the issue similar to #17975 when trying to set the data source properties when using HikariCP. Setting the SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES_SOCKETTIMEOUT environment variable will not work because the Postgres driver expects the case sensitive property socketTimeout.

Is there any update on the status of this ticket? Is it still pending design work or would it be ready for implementation? The suggestion to put the key in the env variable value seems reasonable to me, however I am not clear how you would set multiple key-value pairs. Perhaps:

1. SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES=socketTimeout:180,loginTimeout:60
2. SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES_0=socketTimeout:180 and SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES_1=loginTimeout:60

One advantage I see with 1) would be the possibility to define env variables in different places without needing to worry about setting the index correctly.

ANY_OPTION=socketTimeout:180
ANY_OTHER_OPTION=loginTimeout:60
SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES=$ANY_OPTION,$ANY_OTHER_OPTION

The workaround provided with using SPRING_APPLICATION_JSON is very limited when configuration is defined in multiple places, so please let me know if there is anything I could help with.

[wilkinsona]

Is it still pending design work

Yes, I'm afraid so.

The problem with configuring multiple key-value pairs is really a narrower variant of the problem with using SPRING_APPLICATION_JSON. In addition to that problem, any approach that pushes part of the key into the value will then need a robust way to separate the key from the actual value. I think will require some form of escaping but we haven't had a chance to think about or discuss this in any detail.

please let me know if there is anything I could help with

Thanks very much for the offer. Sharing your experience and ideas is already helpful. Beyond that, I'm not sure that there's much that can be done here at the moment.

[karmann-dm]

Hello, @wilkinsona !

In our internal framework built atop of Spring, we tried the approach of post-processing the config properties beans, where there are map-based properties and for such beans end users (or us) can provide a library-dependent dictionary (for example for Hikari) where all available properties could be fetched/mapped. Then the map got modified using the reflection and applied to a bean.

The example project could be run with the environment variable like SPRING_DATASOURCE_HIKARI_DATASOURCEPROPERTIES_SOCKETTIMEOUT=12300 and verify that the right socketTimeout property was mapped by calling dataSource.getConnection().getNetworkTimeout()

The approach is still pretty raw and some corner cases for the specific libraries should be considered ofc, for example there is a little difference of dictionary composition for Hibernate.

Would that approach make sense? What do you think?

[philwebb]

@karmann-dm I think that's an interesting approach, but I suspect we'd have a lot of trouble keeping the dictionary files in sync. It would be nice if we could offer a hook point so you didn't need to use reflection.