With the following configuration at `bootstrap.yaml`
```yaml
spring:
application.name: spring-cloud-hystrix-dashboard
profiles.active: prod
cloud:
config:
discovery:
enabled: true
serviceId: spring-cloud-server-config-with-eureka
server.port: 9003
turbine:
appConfig: some-service
clusterNameExpression: 'default'
```
I wasn't able to see why Turbine can't find the instance. The reason was related to SPEL:
```
org.springframework.expression.spel.SpelEvaluationException: EL1008E:(pos 0): Property or field 'default' cannot be found on object of type 'com.netflix.appinfo.InstanceInfo' - maybe not public?
```
Anyways there was nothing there in the logs so maybe it should not be silenced like right now?
When the Apache HTTP client is being set up for the Ribbon client we can jump
in and explicitly set a cookie policy. Obviously, since the client will generally
be shared across sessions, the only sensible default is IGNORE_COOKIES.
I couldn't find a way round this without using deprecated APIs (but there
are other instances of that in our code because of the way Netflix uses
it, so maybe that doesn't matter).
Fixes gh-301
This commit resolves an issue where some versions of Cloud Foundry are
setting the 'Connection: close' HTTP header in the Hystrix stream
response, which causes the dashboard to not display the stream data.
See https://github.com/cloudfoundry/gorouter/issues/71
However turbine and zuul are depending on mockito-all in compile-scope. Not only I want to get rid of these (usually) test-dependencies, but also mockito-all contains some hamcrest-classes (in older versions) getting in conflict with the classes from spring-test
It took me quite a bit, to figure out how to configure Zuul to use a loadbalanced route without Eureka. I hope this short explicit example will clarify it for other people.
If the app has a context path then the route locator does not match
the whole requestURI (as provided by the raw servlet API), but Spring
has a utility for stripping it off, so we can just use that.
Fixes gh-270
If there is a default route (/**) then the ZuulHandlerMapping will
mask the /error path in a normal Spring Boot application. This change
makes it a special case so that ZuulHandlerMapping will never map
the /error route (the one specified by the ErrorController).
Fixes gh-284
This was kind of ugly, and caused a static usage of the eureka
DiscoveryCLient to become necessary again, just so the @Bean that is
provided for the user stays accurate (it has to be the one in the main
application context, even if the parent boot strap has different
instance metadata).
I tested with a vanilla Eureka server and config server, and used the
client in tests/eureka-first.
Fixes gh-268