https://github.com/spring-cloud/spring-cloud-netflix/issues/312)

fixes gh-307

fixes 305

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

fixes gh-300

Ignore 'Connection: close' header from stream response

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

Docs: Example of static, loadbalanced Zuul configuration

Exlude mockito all

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

fixes gh-276

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

fixes gh-280

Fixes gh-281

Also fixes gh-277 (metioning starters explicitly).

fixes gh-279

fixes spring-cloud-samples/tests/issues/2

Fixes gh-271, fixes gh-272

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

Fixes gh-274