fixes gh-276

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

Added a LocalApplicationHealthCheckHandler that checks the local app and sends the appropriate status to eureka.

fixes gh-251

removes ugly dagger dependency

fixes gh-183

updated documentation of HystrixHealthIndicator

documentation was not conform to specified behavior as in #24

Simple solution is to check for instanceof before casting.

Fixes gh-265

This change adds more data to the stream with {"type":"Ping"}
so (I believe) the existing dashboard client will discard it,
but stay alive.

Fixes gh-264

Since hostnames ahve quite strict syntax (e.g. no underscores) we should
validate the feign client name to prevent nasty surprises at runtime.

Fixes gh-263

fixes gh-260

Fixes gh-259

Added additional Gradle tip to Eureka Server documentation.

Added additional Gradle tip to Eureka Server documentation. Tip covers the usage of the spring dependency management plugin in order to prevent fatal crashes during application startup.

It turns out that the suckiness of Zuul with multipart requests
comes almost entirely from the Multipart handling in Spring's
DispatcherServlet. This change makes the proxy routes available
on an alternative path /zuul/<normal_path> (where
/zuul is the default value of zuul.servletPath). I have
tested those with 800MB file uploads using the main method in
the FormZuulServletProxyApplicationTests and the main
observation is that there is no OutOfMemory error (no-one tries
to download the complete request body). It works with Ribbon
and with the simple (HttpClient) filter. With Ribbon you
will need to set some timeouts if you want to upload files
as large as that, e.g. see application.yml in the tests:

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 60000
ribbon:
  ConnectTimeout: 3000
  ReadTimeout: 60000

You need to set "Transfer-Encoding: chunked" in the
incoming request. Chrome does not do this by default
apparently, but I was able to test with curl, e.g.

$ curl -v -H "Transfer-Encoding: chunked" \
  -F "file=@mylarg.iso" \
  localhost:9999/zuul/direct/file

The old proxy paths through the DispatcherServlet are still
available (for backwards compatibility and for convenience of
having the paths available at the root of the context path).

Fixes gh-254