The JpaInvokerConfiguration (nested in RefreshAutoConfiguration can be
removed when and if the issue is resolved in Boot.
Also splits the hibernate test dependencies out into a separate module
so the main context tests run quicker.
Fixes gh-355
An actuator endpoint is designed around a single class flagged with
`@Endpoint`. Such endpoint can have some of its operations refined with
a given tech (for instance via a `EndpointWebExtension` for web specific
concerns).
This design mandates that an endpoint (and its tech specific refinements
are managed centrally to form a unified contract).
As Spring Cloud is extending the standard Spring Boot's `env` endpoint,
this commit introduces a WritableEnvironmentEndpoint with a web
extension.
Closes gh-367
Closes gh-354
The test shows that this fixes a weird initialization ordering
problem that leads otherwise to Spring thinking there is a
dependency cycle (even though there is not). This problem only
surfaces when there is a schema.sql to apply.
Fixes gh-355
There could be consequences for apps that have more complex context
hierarchies, but RestartEndpoint doesn't work well at all for those
apps anyway, so we are probably safe to just make changes in the
endpoint itself.
Fixes gh-333
Allows you to apply @RefreshScope to beans that you do not
control or define. The list is configurable as
spring.cloud.refresh.refreshable and by default has only
HikariDataSource.
Fixes gh-318
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.
