for users to get started. It also makes it more flexible if different
aggregation keys are needed depending on the environment. The most
important new feature is the
spring.metrics.export.redis.aggregateKeyPattern configuration, which
fits the *.redis.key and prefix defaults. The aggregate reader uses
a prefix based on the key by default, with a naming convention that
the key starts with "keys.".
Update the Maven and Gradle repackage tasks so that the embedded
startup script is no longer included by default. This change is
primarily due to the `cf` command line not currently accepting
the unusual jar format.
Fixes gh-3045
Users can add @ExportMetric[Reader,Writer] to readers and writers that
they want to participate in the default exporter. There is also still an
@ActuatorMetricWriter that is used for the legacy (non-Java8) Gauge and
CounterServices.
The redis export and aggregate use case is a lot nicer with this
shared data between the two component types.
Also made MetricExportProperties itself a Trigger (so the default
delay etc. can be configured via spring.metrics.export.*).
Remove `spring.cache.config` as it is too generic and does not express
enough what is configured. This property is replaced by cache library
specific properties, that is `spring.cache.ehcache.config`,
`spring.cache.hazelcast.config`, `spring.cache.infinispan.config` and
`spring.cache.jcache.config`.
See gh-2633
Allow SSL to be configured via standard configuration as well as the
requestedHeartbeat. Switch to RabbitConnectionFactoryBean.
Closes gh-2655, gh-2676
User can enable OAuth2 SSO by declaring the intent (@EnableOAuth2Sso)
and also configuring the client properties (spring.oauth2.client.*).
The spring.oauth2.sso.* are only needed to change the path for the
login (defaults to /login) - any other security configuration for the
protected resources can be added in a WebSecurityConfigurerAdapter
which carries the @EnableOAuth2Sso annotation.
- Apply project’s code formatting and conventions
- Don’t use the IO and worker thread configuration when creating the
worker for the AccessLogReceiver. The IO and worker thread
configuration is for HTTP request processing and a worker in its
default configuration should be sufficient for the access log
receiver.
- Don’t use a temporary directory as the default for the access log
directory. A temporary directory makes (some) sense for Tomcat as it
requires a directory for its basedir. Undertow has no such
requirement and using a temporary directory makes it hard to locate
the logs. The default has been updated to a directory named logs,
created in the current working directory.
- Document the new properties in the application properties appendix
Closes gh-3014
Allow the display-name of the application to be customized when deployed
in an embedded container via the `server.display-name` property.
Closes gh-2600
This commit adds CORS support to the Actuator’s MVC endpoints. CORS
support is disabled by default and is only enabled once the
endpoints.cors.allowed-origins property has been set.
The new properties to control the endpoints’ CORS configuration are:
endpoints.cors.allow-credentials
endpoints.cors.allowed-origins
endpoints.cors.allowed-methods
endpoints.cors.allowed-headers
endpoints.cors.exposed-headers
The changes to enable Jolokia-specific CORS support (57a51ed) have been
reverted as part of this commit. This provides a consistent approach
to CORS configuration across all endpoints, rather than Jolokia using
its own configuration.
See gh-1987
Closes gh-2936
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.
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).
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.
