It's not super expensive, but it all adds up, and rebinding beans
that don't need to be rebound is wasteful. This change should improve
things in three places:
The ConfigurationPropertiesRebinder
has always done a pre-emptive re-bind on startup, which was a bit
of a blunt instrument, since all we really wanted as to rebind the
beans in the parent context (to the current context's Environment).
The rebinding always happened twice for every bean because we
explicitly called into the ConfigurationPropertiesPostProcessor
directly as well as indirectly through the initialization callbacks.
Rebinding in response to an EnvironmentChangeEvent was not able to
distinguish between events published locally and by child contexts.
The child context always binds the parent's beans anyway, so you
don't need to do it twice.
A context refresh is actually only trying to recalculate environment
properties. Spring Boot doesn't provide an explicit API for that so
we create a "mini application" to mimic the startup. There is no
need for the logging system to be touched at all, so we can try
and filter out the listeners we know might do that.
Fixes gh-260
We need to tread a very fine line. Ideally the process of refreshing
the Environment builds it back exactly as happened on startup.
In particular we probably don't want to have things like
application.properties already there when we start the process.
This change replaces the more liberal copy of all property sources
only a select few (actually only one), paremeterized as a constant.
In Spring 5.0.0 the SpringFactoriesLoader is stateful and
BootstrapApplicationListener inadvertently modifies the state
by adding class names to a list loaded from spring.factories.
Probably harmless in most apps, but caused some tests to fail
(depending on the order they were run in).
The stub property sources from a web application context do not
contain any properties so they cab't have any effect on
bootstrap. It's cleaner to leave them out of the bootstrap
application context.
If there were *no* bootstrapProperties (i.e. properties added by
PropertySourceLocators) on startup, and then in a refresh event
some new sources were picked up, they would have been added to the
end, instead of the beginning of the list.
Fixes https://github.com/spring-cloud/spring-cloud-config/issues/815
