Primarily when it is needed for metric export.

Adds a separate exporter per MetricWriter and allows individual
configuration of exporters for fine-grained control of schedules
and patterns etc.

Also fix bug in includes/excludes

Different physical sources for the same logical metric just need to
publish them with a period-separated prefix, and this reader will
aggregate (by truncating the metric names, dropping the prefix).

Very useful (for instance) if multiple application instances are
feeding to a central (e.g. redis) repository and you want to
display the results. Useful in conjunction with a
MetricReaderPublicMetrics for hooking up to the /metrics endpoint.

User can add a @Bean of type JmxMetricWriter and get all values
automatically exported in a form that is usable in jconsole
or jvisualvm.

Also rename Codahale* to Dropwizard* and move them to a new package

This seems pretty efficient (approx 12M write/s as opposed to 2M with
the DefaultCounterService). N.B. there is no need to change most of
the rest of the metrics stuff because metrics are write-often, read-
seldom, so we don't need high performance reads as much.

The Spring Integration configuration and Dropwizard support has changed
a bit. Functionally very similar and probably opaque to users, but now
the messaging operates as an Exporter on a @Scheduled method, and
Dropwizard is a replacement [Gauge,Counter]Service.

Metrics are all
collected live in-memory (and can be very fast with Java 8), buffered
there and shipped out to a MessageChannel (if one exists with id
"metricsChannel") in a background thread.

We can still use Java 8 library APIs (like LongAdder) but to compile
to java 7 compatible byte code we have to forgo the use of lambdas :-(
and shorthand generics (<>).

Fixes gh-2682, fixes gh-2513 (for Java 8 and Dropwizard users).

Expose the underlying cache infrastructure bean if Boot auto-configures
it. This is the case for ehCache, hazelcast and JCache. This change has
two side effects:

1. It is now possible to customize the underlying cache infrastructure
and let Boot only wrap it in the Spring's CacheManager abstraction. No
customizations are applied if the caching-specific service is customized
2. Such infrastructure is disposed when the application terminates as
it is now defined as `@Bean` and both `close()` and `shutdown()` methods
are invoked if present on the target type.

While the latter can be troublesome, we feel that a particular cache
instance is not meant to be shared and must be disposed when the
application terminates.

Closes gh-2848

Rework 155c60b7 to structure the code consistently, in particular with a more
natural order of attributes. Update test to use non-default values to ensure
that the customization has been applied.

See gh-2793

Update the CLI init command to expose additional attributes supported
by Spring Initializr. These are: groupId, artifactId, version, name,
description and language.

Closes gh-2793 and gh-2907

Document new configuration properties and remove redundant code

This commit adds support for configuring the JSP servlet’s init
parameters via the environment using server.jsp-servlet.init-parameters.*.
As part of this change the configuration of registerJspServlet and
jspServletClassName have been moved onto a new type, JspServlet, and the
existing setters on ConfigurableEmbeddedServletContainer have been 
deprecated. In addition to providing a model for configuring the JSP
servlet that’s consistent with the model for other configuration (SSL,
for example), this change also means that the class name and whether or
not the servlet is registered at all can now also be configured via the
environment.

Closes gh-2825

Some of the features of the launch.script were not exposed for users
to be able to control at runtime. It now accepts things like
PID_FOLDER and LOG_FOLDER as environment variables, and also adopts
a clear naming convention where only the inputs are UPPER_CASE.

Previously, CommonsLoggingLiquibaseLogger referred to its
configured level and the underlying Commons Logging log when
determining if logging was enabled for a particular level. This did
not work as intended as setLogLevel was never called leaving the
configured level stuck at its default value of INFO. As a result of
this any logging at levels below INFO would not be output,
irrespective of the configuration of the underlying logging framework.

This commit updates CommonsLoggingLiquibaseLogger to rely purely on
the Commons Logging log when determining whether or not logging for
a particular level is enabled. This brings the implementation into
line with liquibase-slf4j [1] which provides similar functionality,
albeit using SLF4J rather than Commons Logging

Closes gh-2916

[1] https://github.com/mattbertolini/liquibase-slf4j/blob/master/src/main/java/liquibase/ext/logging/slf4j/Slf4jLogger.java

Closes gh-2935

Previously, when SpringApplicationContextLoader created a
SpringApplication and used it to load the test’s application context,
it relied upon SpringApplication correctly deducing the application’s
main class. This would result in the wrong class being deduced as the
application’s main method is not called so the test runner’s main method
would be found instead.

This commit updates SpringApplicationContextLoader to explicitly set
SpringApplication’s main class to be the current test’s class. While
not strictly the application’s main class, it is the next best thing
available in this situation and prevents misleading log messages and
application versions from being logged.

Fixes gh-2930

When a Java 8 JVM is launched with -XX:MaxPermSize a warning message
is output indicating that the option will be ignored. This causes the
CLI tests that assert that no error output has been produced to fail.

This commit updates the CLI's integration test harness to remove
JAVA_OPTS from the environment of the CLI process. This prevents any
unwanted max perm size configuration from leaking into that
environment and breaking the build.

When a Java 8 JMV is launched with -XX:MaxPermSize a warning message
is output indicating that the option will be ignored. This causes the
CLI tests that assert that no error output has been produced to fail.

This commit updates the CLI's integration test harness to remove
JAVA_OPTS from the environment of the CLI process. This prevents any
unwanted max perm size configuration from leaking into that
environment and breaking the build.

Closes gh-2928

Closes gh-2931

Closes gh-2932

Closes gh-2754

Spring Framework 4.2 introduces improved support for CORS. Notably this
means that a DispatcherServlet will now process an OPTIONS request if
it contains an Origin header, without having to enable OPTIONS request
dispatching for every endpoint.

This commit takes advantage of these changes in Spring Framework 4.2 by
configuring the controller that wraps Jolokia’s AgentServlet to handle
OPTIONS requests. This allows Jolokia’s CORS support to be configured
using Jolokia’s standard configuration, as described in section 4.1.5
of the Jolokia documentation [1].

Closes gh-1987

[1] https://jolokia.org/reference/html/security.html

For reasons that I don’t understand, Maven has decided to stop running
the javadoc:jar task as part of the package phase. It appears to be
related to the addition of the build-helper plugin in
spring-boot-dependencies. Binding javadoc:jar to the prepare-package
phase convinces Maven to run it, apparently without any unwanted side
effects.

Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.

This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.

Closes gh-2688
Closes gh-2439

While this is a breaking change, continuing with Spring Social
Facebook 1.1.x is also broken as it is no longer compatible with
Facebook's API. Upgrading to 2.0.1.RELEASE may require some changes
to be made to users' applications, but it will allow their
applications to use the Facebook API once again.

Closes gh-2837