@ConfigurationProperties should have an option to have properties read each time from Environment

[philwebb]

Originally raised on the SPR issue tracker:
https://jira.springsource.org/browse/SPR-11289

@ConfigurationProperties objects should have some mechanism for allowing some or all properties to be read from a propertySource on each get invocation. It seems like instead of injected a concrete implementation into the AppContext we should inject a proxy for the Config object which can reference the Environment abstraction.

The usecase for this would be when we have implemented a custom PropertySource which is aware of property changes.

[dsyer]

Sounds like a wider scope than just @ConfigurationProperties to me. Doesn't the same feature potentially apply to any bean that can refresh itself on an environment change?

That is leaving aside the question of whether this is a good idea or not. Is it a good idea? In a world of stateless micro-services isn't it better to just change the config and restart the app? Or are we mainly talking about development time? What's the benefit exactly?

[philwebb]

I am not sure if the original author is watching this or not.

I agree, this might not be a great idea. Dynamically reloading properties can be a tricky problem, often just updating the @ConfigurationProperties object won't be enough, you need more of an event based approach so that other classes are aware of the change.

I also can't see this being a very common use-case.

Perhaps we can add some hooks to allow a roll-your-own solution if 'getting on each invocation' is really needed?

[twicksell]

Hey, I was not watching the issue from github, sorry about that. I'm the author of the request.

I do not believe this has anything to do with beans other than @ConfigurationProperties, or at least that isn't something I'd want. To give a little more background on what I'm doing, I've got an implementation of Netflix's Archaius (https://github.com/Netflix/archaius/wiki/Users-Guide) hidden under Spring's PropertySource. Archaius provides some great support for property change listeners, reloading properties, etc. that we use pretty heavily at Netflix, but being a Spring person I greatly prefer being able to use @Value, Environment, spel property resolution, and @ConfigurationProperties whenever possible. Hence the NetflixPropertySource implementation. Of course @Value doesn't work since its only reading the property once on startup/bean creation, and I don't think I'd want that to change honestly, but with @ConfigurationProperties would be much easier to implement delegation to the Spring Environment. I'd argue it should always delegate to the PropertySources, and if you're concerned about performance/caching let that be the concern of your PropertySource implementation.

As to whether or not reloadable configuration is a good idea in a world of micro cloud services, I'd just point out that this new cloud world isn't quite perfect yet. For us, rolling out new clusters into AWS (with sizes ranging from dozens to 100+ per app cluster) can take 45minutes just to get started and perhaps hours for caches to become warm. Because of that we often find it necessary to use feature flags based on properties to enable/disable functionality across our entire cloud infrastructure. This is something Archaius does rather nicely, and its just a shame at the moment I can't leverage @ConfigurationProperties as much as I'd like to for working with Archaius.

Any kind of hook to allow me to customize the creation of @ConfigurationProperties would be sufficient, but I do suggest considering delegation to the Spring Environment as an option, if not the default behavior.

[andrewharmellaw]

Hi,

We're very interested in this discussion, and the recent announcement about dynamic Spring props. We've built https://github.com/Capgemini/archaius-spring-adapter which sounds like it overlaps heavily with what @twicksell has been working on. We'd be interested in being involved in work in this area as it'd help us greatly on our current project.

[dsyer]

@andrewharmellaw our archaius bridge is here: https://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-core/src/main/java/org/springframework/cloud/netflix/archaius. It would be good to get feedback, or pull requests if you like, via that project.

[andrewharmellaw]

Cheers @dsyer We'll take a look and see if we can contribute. We're big users of Spring (Boot especially), Camel, and various Netflix bits and pieces too. Anything which helps glue them together which is OSS is of interest to us.

[rachelwilson]

I was wondering if someone could point me (and other readers) in the direction of the "recent announcement about dynamic Spring props" as mentioned by andrewharmellaw above. I was interested to hear what the latest thinking is and I cant seem to find anything recent.

[dsyer]

Try here: http://projects.spring.io/spring-cloud/spring-cloud.html#_environment_changes (and some other bits of that section).

[rachelwilson]

Hmm, that seems to be documentation rather than an announcement as such. Can I assume in that case that the dynamic properties apply only to the Cloud and Boot products and there are no announced changes to the original Spring framework?

[dsyer]

Yes, it's a Cloud feature right now (but with really minimal dependencies, as long as you are using Spring Boot).

[nmarasoiu]

@dsyer Hi, I am having this issue with Spring Cloud: I added a MapPropertySource to the env, I am changing the values from the ConcurentMap from another thread, but I can't see those values reflecting in env.getProperty or in @ConfigurationProperties beans. Pls advise!

[dsyer]

If you really changed the environment, you would see it in getProperty(), so if you didn't see it there, then I suspect you didn't change it, or you changed a property that is overridden in another property sourec. You can see all the property sources in the /env endpoint.

You have to rebind to get @ConfigurationProperties to update, so that's a different problem. There's a ContextRefresher in spring-cloud-context that you can use if you want to trigger it manually, or you can use the /refresh endpoint.