There are usually some hints available, especially if the Server
came from Eureka. Unfortunately Server on it's own doesn't contain
enough information (why?), but as a fallback we can guess that
anyone using port 443 is secure.
Fixes gh-459
Remove Servo from EurekaHealthIndicator.
Remove custom DataCenterInfo.
EurekaInstanceConfig.SID is now used as eureka id.
EurekaInstanceConfigBean.getSID falls back to metadataMap.instanceId for
backwards compatibility.
And also when using eureka-first for discovering config server.
The EurekaClient is very rigid and initializes itself, registering
with the remote service on instantiation. Hance it needs to be
in @RefreshScope for it to be properly refreshable. Doing that
leads to a sequence of other changes (e.g. to account for the
fact that there is no @RefreshScope in bootstrap context).
Fixes gh-551
When the parent (bootstrap) context registers the app as well as consuming
the registry it causes problems, e.g. when you refresh that context is
re-created and destroyed, which tends to unregister the app and it's hard
to get it back. It is simpler if the parent context use eureka read-only.
To ensure this we have to remove the @EnableDiscoveryClient from the
bootstrap context.
Tested with vanilla config server and eureka with the 'eureka-first'
sample and the 'zuul-proxy-eureka' sample.
Fixes gh-421
Reverts part of a change made for gh-349 and rationalizes a bit of the
Eureka configuration. The Eureka client cannot be shutdown without
attempting to restart it (but there isn't an obvious public API for
that), so it's better not to shut it down at all.
See gh-421
Move turbine/hystrix amqp specific implementations to spring-cloud-stream based implementations and let the user decide which broker to use.
fixes gh-545
If the zuul reverse proxy and the destination services are using a different scheme
(for example HTTPS on proxy side and HTTP on service side) an additional HTTP
header is required according to RFC7239 [http://tools.ietf.org/html/rfc7239]