https://github.com/spring-cloud/spring-cloud-netflix/pull/1372 has been
merged. So it is save to remove the local workaround.

closes #404

With this commit you can now associate your applications with custom
metadata using `spring.boot.admin.client.metadata.*` sensitive values
are recognized by key and are masked in the http interface.

This can be useful in the future if there are instance specific settings
which should be used by the admin server, e.g. custom notification
recipients.

For now there is no extra imetadata view in the ui. The values are shown
in the environment view.

From this commit on the source from wich the application was registered
is remembered. We use this information for two things:
 * For applications which wasn't registered via the http-api the remove
   button is hidden.
 * The `ApplicationDiscoveryListener` only removes stale applications
   (those which are not anymore found via discovery) if the were registered
   via the `ApplicationDiscoeryListener`.

closes #328

With this commit the concept of an ApplicationFactory is introduced.
This allows you to easily modify the information used to register
your application at the admin server

closes #331

The managment.ssl.* properties needs to be taken into account when they
are explicitly set and the managment.port differs from server.port

fixes #333

With this commits the server no longer depends on the client. The
classes for the clients are moved to de.codecentric.boot.admin.client
package.
Since the perspective on applications is totally different from client
and server the model has been split apart.

What means this for users:
1) The client is no longer a transitive dependency for your admin server
you may need to add it explicitly to your dependencies, respectively
jolokia-core in case you're using discovery and want to use the jmx-bean
interface

2)In case you have cutomised parts of the client you need to reflect the
package change.

fixes #332

Since the actuator mvc endpoint beans live in a child context when the
server and management port aren't the same, the admin client shouldn't
depend on those beans.

fixes #302

If server.address or management.adress is set use it's value to resolve the
hostname used for management-/service-url.

With the fix for #260 we ignored all events from child contexts which turns out
to be wrong since the "main" application context is, in case spring cloud config
is used, is a child  of the bootstrap context. So we just act on the events from
WebApplicationContexts. After they're fired up the needed port information is
available.

fixes #277

When includeing spring-cloud-netflix-hystrix-amqp to your application it looks
like that the ApplicationReadyEvent is fired twice (from main and child
application context). So we need to take care that only the events from the
main applications are taken into account.

fixes #260

With this commit you can from now on register the application on multiple
servers. You need to set spring.boot.admin.register-once to false and
assign a list of urls to spring.boot.admin.url

fixes #230

This commit contains multiple changes:
 - Start the registration task after the ApplicationReady event. This makes
   AdminClientProperties.isReady() unnecessary.
 - The RegistarApplicationListener has two new public methods to start/stop the
   periodic registration task.
 - Add spring.boot.admin.auto-registration property (default: true). When this
   property is set the registration task is automatically scheduled after the
   ApplicationReadyEvent.

closes #151

In case prefer-ip is true and no server.address is set use the IP address from
InetAddress.getLocalHost(); like it is done in Eureka.

Add spring.boot.admin.client.enabled property to explicitly disable the
spring-boot-admin-client, (e.g. for unit tests). Defaults to true. The client is
active when spring.boot.admin.client.enabled is true and spring.boot.admin.url
is set.

fixes #156

In case you have clustered admin servers, you can now specify multiple urls for
the client to register at. So that in the case the first server is down it will
register at the next one specified in the list. This allows you to do cluster-
ing without the need for a load-balanced host.

Take the servlet-path into account when computing the management-/healht-url.
This is not done for the service-url, since the main use-case for setting the
servlet-path is to get the dispatcher-servlet out of the way for other servlets.

fixes #133

By using local.server.port, local.managment.port and ApplicationReadyEvent the port detection and ready state detection can be simplyfied in boot 1.3

remove logfileEndpoint
rename logback.xml to logback-spring.xml in samples

fixes #98

 * Use @EventListener instead of ApplicationListener-interface
 * Don't inherit ClientApplicationEvent from ApplicationEvent - so JournaledEvent isn't needed anymore
 * added eclipse formatter rules
 * reformatted all files

In conjuntion with server.address / management.address this plays more nicely with interfaces with multiple ipAdrresses. Also remove spring.boot.admin.client.useAddressOf.

fixes #112

There is currently a problem if the Admin Client has version 1.2.0 and the Admin Server has version 1.2.1 due to changes to the model. The server is able to handle the old format but the client is not able to handle the new Format. To prevent this problem in future the response is not deserialized. Only the needed inforamtion (the id) is exctracted.

Added inner-class for admin client registration configuration which is
conditional on spring.boot.admin.url. Logfile endpoint is now available
when just using Spring Cloud Discovery.

The health-check is made at a fixed interval (default: 10s) for all expired status-information (default-lifetime: 30s).
The application health-endpoint must either respond with a JSON-Body having a status-field or with an empty body and all 2xx-http-responses are interpreted as UP and every other status as DOWN.

If `spring.boot.admin.client.useIpAdressOf=<network-interface>` is set properly the ip-address of the specified network-interface is used in the inferenced url to register with.
In case the address cannot be determined an exception is thrown and the client won't register.
This is for example useful in Docker environments making the inferenced urls work.

Checks for the presence of Ssl in ServerProperties and that it is
enabled, uses https in that case for client URL. Added test case for
option.

fixup! Add optional automatic deregistration on shutdown - turned off by default; only periodically try to register when the context is active

fixes #62

This change not only allows you to use `context-path` and `contextPath` but also respects automatic port assignment when using `server.port=0` or `managment.port=0`.
Also corrects the value if server.port != mangement.port and server.context-path and management.server-path is set.
fixes #57