Followup of #1547 since it has been locked.
Cherry picking an example of my rationale then locking the issue is at least not fair.
Since when do we have to explain why immutability and encapsulation are good things? Here is a non exhaustive list of what can't be changed in Spring Boot by the application developers after initialization: - Bean registry - Environment property source registry - Constructor injected beans dependencies
And the list goes on.
Now, from the last message, I understand that what I am asking may not be easy. But dismissing it as useless is at least not fair.
Comment From: spencergibb
That's fair. I apologize. The scope, to me, is still beyond what I want to support. There is still a dichotomy to me of an immutable class that you want to change (doesn't matter the source of the change).
Comment From: spencergibb
After talking with the team, we're going to keep immutable properties as the marker to not refresh.
Comment From: rmpestano
Hi everyone, sorry for replying to an old issue but can't we have a warn or do not return any property after trying to refresh immutable properties? right now refresh endpoint returns the properties as if they were updated.
Thanks for the great work!
Comment From: rmpestano
Hi everyone, sorry for replying to an old issue but can't we have a warn or do not return any property after trying to refresh immutable properties? right now refresh endpoint returns the properties as if they were updated.
Thanks for the great work!
Ahh never mind, the properties are indeed refreshed and accessible through env.getProperty, just the ConfigProperty beans aren't being refreshed.