If I change a property/YAML value in a local configuration file, I want the Environment object to be able to read from the file again (i.e refresh its values).

Online research mentions using Spring Cloud Config, Spring Boot actuator, etc, which are all really cumbersome to adopt for such a simple thing.

Any plans to enhance Environment?

For example:

  • environment.refresh() to refresh all its configuration values
  • environment.getProperty("myKey", true) to refresh a specific key -- true means refresh; default can be false.

Comment From: orlandolorenzo724

I agree!

Comment From: hannah23280

How do i shift this post over to Spring framework issues? Sorry, cos on 2nd thought , i realize this request is more appropriate for spring framework than spring boot.

Comment From: sbrannen

Thanks for the proposal, @hannah23280.

  • environment.refresh() to refresh all its configuration values

This would not provide any benefit, since properties are pulled from the Environment (via getProperty(...)) instead of the Environment pushing properties to consumers.

  • environment.getProperty("myKey", true) to refresh a specific key -- true means refresh; default can be false.

Similar to the above, a boolean refresh flag would not provide any benefit since a getProperty(...) invocation already queries underlying PropertySource implementations for the "current" value.

Thus, in order to achieve your goal of refreshing the value of a given property, the PropertySource responsible for that property would need to perform its own refresh/reload for the underlying source of the properties.

For example, instead of using a PropertiesPropertySource, you could implement your own custom PropertySource which always retrieves properties from a .properties file in the filesystem or classpath instead of caching those properties in a java.util.Properties object.

In light of that, I am closing this issue.

Comment From: hannah23280

Thanks for the proposal, @hannah23280.

  • environment.refresh() to refresh all its configuration values

This would not provide any benefit, since properties are pulled from the Environment (via getProperty(...)) instead of the Environment pushing properties to consumers.

Environment.refresh() merely reload the configuration values from files, environment variable into the environment object, so that the environment is loaded with "fresh" values. Then developer can get the "fresh" value as per normal (i.e using environment.getProperty). There is no "pushing properties to consumers" involved.

  • environment.getProperty("myKey", true) to refresh a specific key -- true means refresh; default can be false.

Similar to the above, a boolean refresh flag would not provide any benefit since a getProperty(...) invocation already queries underlying PropertySource implementations for the "current" value.

But the framework can also introduce a new environment method called getRefreshedProperty() (example only) for such purpose?

Thus, in order to achieve your goal of refreshing the value of a given property, the PropertySource responsible for that property would need to perform its own refresh/reload for the underlying source of the properties.

For example, instead of using a PropertiesPropertySource, you could implement your own custom PropertySource which always retrieves properties from a .properties file in the filesystem or classpath instead of caching those properties in a java.util.Properties object.

In light of that, I am closing this issue.

Why not provide another built-in PropertySource , such that it always retrieves properties from the file, or a flexible PropertySource that has the flexibility to retrieve value that is already loaded, or re-retrieve from file again, depend on user needs.

Do note that the discussion here might not refer to just properties file. It can be OS environment variable, yaml files, and whatever possible property sources that spring supports

Unless such use case is rare, otherwise i thought it would benefit many of developers down the road.

Comment From: hannah23280

That said, i do hope that this issue can be re-opened, if number of supporters is high enough..