Add an annotation processor that generates properties files for certain
auto-configuration class annotations. Currently attribute values from
@AutoConfigureOrder, @AutoConfigureBefore, @AutoConfigureAfter and
@ConditionalOnClass annotations are stored.
The properties file will allow optimizations to be added in the
`spring-boot-autoconfigure` project. Primarily by removing the need
to ASM parse as many `.class` files.
See gh-7573
Update Spring Integration metrics support since Spring Integration
`4.3.6`+ no longer needs `spring-integration-jmx` enable
`MessageChannel`, `MessageHandler` and `MessageSource` metrics.
- Add `IntegrationManagementConfiguration` conditional auto-configuration
to provide `@EnableIntegrationManagement` when JMX is `enabled` or there
is no `IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean.
By default this bean doesn't exist and you explicitly should declare it
(e.g. via `@EnableIntegrationManagement`) if you would like to collect
metrics. At the same time Spring Integration enables it when JMX
management is present (that is a purpose of that new
`IntegrationManagementConfiguration`)
- Change `SpringIntegrationMetricReader` to read metrics from the
`IntegrationManagementConfigurer`, not `IntegrationMBeanExporter`
- Change `PublicMetricsAutoConfiguration` to register
`IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean if
not present. Since we are here in `actuator`, therefore we are
interested in the metrics for SI as well.
- Since we don't need JMX for the metrics any more, remove SI-JMX
dependency from the `spring-boot-starter-integration`.
- Remove `IntegrationManagementConfiguration` modification from the
`integrationMbeanExporter()`, since that looks like mutation of an
external object, when end-user would prefer their own options.
Therefore we don't need `ObjectProvider<IntegrationManagementConfigurer>`, too
- Add missed `MessageSourceMetrics` gathering for the
`SpringIntegrationMetricReader`
Closes gh-7722
Previously, when access logging was enabled and the management server
was running on a separate port, both the main server and the management
server would write their access logs to the same file. Having two
separate containers writing to the same file could cause problems such
as causing log rotation to break.
This commit updates the actuator so that when the management server is
running on a separate port (and therefore using a separate container)
it prepends management_ to the access log prefix so that the main
server and the management server write their access logs to separate
files in the same directory.
Closes gh-6618
This commit changes the default version of Tomcat to 8.5.3 while
also retaining support for Tomcat 8.0 and 7.0. The main difference
in 8.5 is that the ServerSocketFactory abstraction that allowed the
TrustStore and KeyStore to be configured programatically no longer
exists. This logic has been replaced with the use of a custom URL
protocol (springbootssl) that provides access to the key store and
trust store of an SslStoreProvider. In addition to working with 8.5,
this approach has the advantage of also working with 8.0 and 7.0.
Closes gh-6164
This commit adds a Jest-based health indicator for ElasticSearch. If both
Jest and the Spring Data are available, the latter takes precedence as it
provides more information.
Closes gh-3178
This commit simplifies the Jackson-related auto-configuration that’s
applied when Spring HATEOAS and Spring Data REST are on the classpath.
Previously, Boot used Jackson2HalModule to apply the HAL-related
ObjectMapper configuration to the context’s primary ObjectMapper. This
was to allow HAL-formatted responses to be sent for requests accepted
application/json (see gh-2147). This had the unwanted side-effect of
polluting the primary ObjectMapper with HAL-specific functionality.
Furthermore, Jackson2HalModule is an internal of Spring HATEOAS that
@olivergierke has asked us to avoid using.
This commit replaces the use of Jackson2HalModule with a new approach.
Now, the message converters of any RequestMappingHandlerAdapter beans
are examined and any TypeConstrainedMappingJackson2HttpMessageConverter
instances are modified to support application/json in addition to their
default support for application/hal+json. This behaviour can be disabled
by setting spring.hateoas.use-hal-as-default-json-media-type to false.
This property is named after Spring Data REST’s configuration option
which has the same effect when using Spring Data REST. The new property
replaces the old spring.hateoas.apply-to-primary-object-mapper property.
Previously, when Spring Data REST was on the classpath,
JacksonAutoConfiguration would be switched off resulting in the context
containing multiple ObjectMappers, none of which was primary.
This commit configures RepositoryRestMvcAutoConfiguration to run after
JacksonAutoConfiguration. This gives the latter a chance to create its
primary ObjectMapper before the former adds its ObjectMapper beans to
the context.
Previously, the actuator’s hypermedia support assumed that the
HttpMessageConverters bean would contain every HttpMessageConverter
being used by Spring MVC. When Spring HATEOAS is on the classpath this
isn’t the case as it post-processes RequestMappingHandlerAdapter beans
and adds a TypeConstrainedMappingJackson2HttpMessageConverter to them.
This wasn’t a problem in the past as the primary ObjectMapper, used by a
vanilla MappingJackson2HttpMessageConverter, was configured with Spring
HATEOAS’sJackson2HalModule. Now that this pollution has been tidied up
the assumption described above no longer holds true. MvcEndpointAdvice,
which adds links to the actuator’s json responses, has been updated
to look at the HttpMessageConverters of every
RequestMappingHandlerAdapter when it’s trying to find a converter to
use to write a response with additional hypermedia links.
Integration tests have been added to spring-boot-actuator to ensure
that the changes described above have not regressed the ability to
configure its json output using spring.jackson.* properties (see
gh-1729).
Closes gh-3891
When Spring Data REST is owning the home page it has its own
HandlerMapping with a fix (relatively) low priority. The /links
endpoint wants to own the home page as well, and our handler mapping
has a high priority for good reasons. This change addresses the
issue by checking if Spring Data REST is configured and if
the management context path (or more specifically, the links
endpoint) is the same as the home page.
Fixes gh-3486
If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
In principle you might have multiple "system" repositories, all
of which you want to go to public metrics or not be metrics exporters.
This change adds a new annotation and renames the old one, so that
reades and writers can be distinguished, and also changes the
autowiring of them to accept multiple values.
Also adds automatic public metrics for Spring Integration.
This avoids a potential problems with ordering between Dropwizard and
normal repository configuration. A Dropwizard sample has been added to
verify the behaviour.
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).
Add an abstraction that provides a standard manner to retrieve a
statistics snapshot of a cache.
Specific implementations for JSR-107, ehcache, hazelcast, guava and
concurrent map are provided. At the moment the size of the cache and
the hit/miss ratios are recorded. Cache metrics are exposed via the
`cache.` prefix followed by the name of the cache. In case of conflict,
the name of the cache manager is added as a qualifier.
It is possible to easily register a new CacheStatisticsProvider for an
unsupported cache system and the CacheStatistics object itself can be
extended to provide additional metrics.
See gh-2633
Closes gh-2770
- Nest the configuration class in HealthIndicatorAutoConfiguration,
bringing it into line with the other health indicator configuration
classes
- Include the statistics from the response in the health’s details
- Map YELLOW to UP rather than UNKNOWN as it indicates that the cluster
is running but that “the primary shard is allocated but replicas are
not” [1]. The details can be used to determine the precise state of
the cluster.
- Add a property to configure the time that the health indicator will
wait to receive a response from the cluster
- Document the configuration properties
- Update the tests to cover the updated functionality
See gh-2399
[1] http://www.elastic.co/guide/en/elasticsearch/reference/1.x/cluster-health.html
Spring Buildmaster
Madhura Bhave
Eddú Meléndez
Phillip Webb
Artem Bilan
Stephane Nicoll
Andy Wilkinson
Michael Hunger
Julien Dubois
Martin Lippert
Dave Syer
Binwei Yang