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.

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

As it turns out (rather obvious) that the ThreadPools for registration and
status updating needs to be destroyed on application shutdown so that the
worker threads gets cancelled. To achieve this we simply register the
ThreadPools as spring beans (since they are implementing DisposableBean).

fixes #253

Apparently when the Netty4ClientHttpRequestFactory is being used the content-
lenght header is not being set in the POST request. Therefore the simple one is
now being hardcoded to override decetion by the RestTemplateBuilder.

fixes #248

Fix the usage of RestTemplateBuilders which wasn't covered by PR #247

The RestTamplateBuilder doesn't save the arguments, it returns a new Builder instance, with the saved arguments. So you have to save the builder everytime you call a function on it.

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

Update to Spring Cloud Brixton and add the concept of ServiceInstanceConverters.
A ServiceConverter is used to convert discovered ServiceInstances to
Applications. The old converter and one for Eureka is provided. It is also
possible to provide your own implementation.

closes #154

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.

There is a problem with the relaxed binding for system environment variables in
spring boot and ignoreUnknownFields for ConfigurationProperties. So we need to
remove it for now.

fixes #135

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

changed constructor visibility from private to protected in order to be able to derive from Application

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.