Previously, waitsForQuietPeriod would iterate 10 times, touching a new
file and then sleeping for 100ms at it did so. With a quiet period of
200ms, this was intended to result in a single change set containing
10 files. However, the test would fail occasionally as multiple change
sets were detected. The test is multi-threaded and is, therefore, at
the mercy of the scheduler. If the thread that is iterating and
touching the files takes over 200ms to be scheduled – exceeding the
watcher's quiet period – the watcher may detect a change set while the
changes are still being made. Eliminating this possibilty would require
the test to participate in the watcher's synchronization, which would
require some changes to its implementation. Instead, this commit
aims to avoid the problem by sleeping for 1/10 of the time (10ms) and
expecting a single change set of 100 files. The hope is that the much
shorter sleep time will result in the file touching thread being
scheduled well within the 200ms quiet period.
Closes gh-22732
Prior to this commit, an entry in the environment map provided to the
build plugin image building goal or task that had a null value would
result in a failure with a message that was difficult to diagnose.
This commit treats env map entries with a null value as an empty
entry to prevent the failure and also make it easier to provide an
explicit empty entry in the Maven XML.
Fixes gh-22703
Prior to this commit, the livenessState and readinessState health
indicators would not be configured automatically and would be missing
from the "liveness" and "readiness" health groups, leading to 404s when
hitting the `/actuator/health/liveness` or `/actuator/health/readiness`.
This commit ensures that the health indicators beans have the proper
name and revisits the auto-configuration conditions to reflect that as
well.
Fixes gh-22562
This commit harmonizes dependency declarations for Jackson in the
actuator. Both Jackson and JSR 310 are back to optional in the core
actuator module and mandatory when using the auto-configuration.
Closes gh-22624
Prior to this change, TaskExecutorBuilder used seconds as its precision
to map the awaitTerminationPeriod value. This caused a loss of
millisecond information in the period.
This commit fixes the loss by converting the period to millisecond and
using setAwaitTerminationMillis to configure the executor.
See gh-22604
Previously, ignoring invalid fields would cause the failure for an
unknown field to be ignored, irrespective of the ignoreUnknownFields
attribute on `@ConfigurationProperties`.
This commit updates the NoUnboundElementsBindHandler to ensure that
any UnboundConfigurationPropertiesException is thrown rather than
being ignored when the handler has been wrapped by an
IgnoreErrorsBindHandler.
Fixes gh-22308
The fix for gh-20916 updated DefinitionsParser so that the
ResolvableType for each MockBean or SpyBean field included the
implementation class from which the field was found. Where the field
was declared with a variable generic signature that was made constant
by its implementation class, this allowed the correct concrete type to
be determined. It also had the unintended side-effect of preventing two
test classes with identical `@MockBean` and `@SpyBean` configuration
from sharing a context as the resolvable types for their mock and spy
bean fields would now be different.
This commit updates DefinitionsParser to only include the
implementation class in the ResolvableType if the field's generic type
is variable. For cases where it is not variable, this restores the
behaviour prior to the fix for gh-20916.
Fixes gh-22566
Previously, background pre-init was started in response to the
application starting event. This meant that it would be running while
the logging turbo filter was in place and was rejecting all logging.
As a result, any logging performed during pre-init would be lost.
This commit changes background pre-init so that it is now started
in response to the application environment prepared event. By this
point, the logging turbo filter has been removed as the logging levels
have been configured from the environment.
Closes gh-21897
Previously, only UndertowOptions was used as the source of options for
both server and socket options, but it only contains server options.
As a result, attempting to configure any socket options defined by
XNIO's Options class would fail.
This commit updates the property-based configuration of options to use
UndertowOptions as the source for server options and XNIO's Options as
the source for socket options.
Fixes gh-22502
This commit fixes the auto-configuration of the Couchbase caching
support by configuring the cache once Spring Data Couchbase has gotten
a chance to be processed.
Closes gh-22542
The generated snippets were not declared as an output to the
`spring-boot-actuator-autoconfigure` test goal so when the test was
pulled from the cache, it did not contain the `generated-snippets`
directory. This directory is required as an input to the Asciidoctor
plugin.
See gh-22555
This adds build caching and build scans.
The changes required disabling scans when using the maven invoker
plugin in order to not cause duplicate build scans when invoking other
maven builds. There is also an empty `.mvn` folder in the
spring-boot-starters project to prevent duplicate build scans as well
since there is no way to pass properties to the maven-javadoc-plugin.
The checkstyle plugin was causing a cache miss with the
`propertyExpansion` because it contains an absolute path. The absolute
path is now ignored and instead the files are added as inputs to the
checkstyle plugin. This only enables the local build cache. The remote
cache is not yet enabled.
On my local machine:
./mvnw clean install build times go from about 30 minutes to about 10 minutes.
./mvnw clean install -Pfull build times go from about 60 minutes to about 13 minutes.
See gh-22089
Prior to this commit, the application availability infrastructure
would mix the `AvailabilityState`, the `HealthIndicator` and the
`HealthGroup` concepts and would not align with the rest.
This commit auto-configures the livenessState and readinessState
health indicators with the relevant configuration properties.
Unlike other indicators, they are not enabled by default but might
be in future versions.
This also moves the `management.health.probes.enabled` property
to `management.endpoint.health.probes.enabled` since "probes" here
is not a health indicator but rather a configuration flag for the
health endpoint.
Finally, the probes auto-configuration is refined to automatically
add liveness and readiness indicators for the probes group if
they're not already present.
Closes gh-22107