Previously, a number of Elasticsearch properties were duplicated
across the spring.elasticsearch.rest and
spring.data.elasticsearch.client.reactive prefixes for configuring
the blocking REST client provided by Elasticsearch and the reactive
client provided by Spring Data respectively. This could cause
problems when using the Elasticsearch REST client configured with
a custom spring.elasticsearch.rest.uris. If Spring WebFlux (to make
use of WebClient) and Spring Data Elasticsearch were on the classpath,
the reactive Elasticsearch Client would be autoconfigured but it
would use the default value of its analogous
spring.data.elasticsearch.client.reactive.endpoints property. It
would be unable to connect, causing a startup failure.
This commit consoliates the configuration properties where possible.
Each setting that is common across the two clients is now configured
using a single, shared spring.elasticsearch property. Each setting
that is specific to the blocked REST client or the WebClient-based
reactive client now have prefixes of spring.elasticsearch.restclient
and spring.elasticsearch.webclient respectively.
The old properties beneath spring.elasticsearch.rest and
spring.data.elasticsearch.client.reactive have been deprecated. If a
any deprecated property is set, all of the new properties are
ignored. In other words, to migrate to the new properties, each usage
of a now-deprecated property must be updated to use its new
replacement instead.
Closes gh-23106
The auto-configuration requires `HtmlUnit`, so this auto-cofiguration
only works if both Selenium and HtmlUnit are used.
Prevents misinterpretation that WebDriver can be auto configured without
htmlunit.
See gh-27920
Edit the actuator docs so that more "You can..." phrasing is used.
For example
"Auditing can be enabled by providing"
becomes
"You can enable auditing by providing"
See gh-27759
Update example lead-in text to a slightly shorter form.
For example
"as shown in the following example"
Becomes
"as the following example shows"
See gh-27759
As of Spring Framework 5.3, `WebTestClient` can now be configured on top
of `MockMvc` for testing Spring MVC applications in a mock environment.
Prior to this commit, `WebTestClient` would be already configured for
WebFlux mock setups with `@AutoConfigureWebTestClient` or live servers
(for both MVC and WebFlux apps).
This commit enhances the `@AutoConfigureWebMvc` support so that a
`WebTestClient` instance is auto-configured if the spring-webflux
dependency is present on the classpath.
Closes gh-23067
* gh-26258:
Polish "Refine documentation"
Refine documentation
Polish "Add properties for Dynatrace metrics API v2 ingest with Micrometer"
Add properties for Dynatrace metrics API v2 ingest with Micrometer
Closes gh-26258
The documentation overview sections is supposed to provide a map
for the rest of the reference document. The getting help and upgrading
sections were moved to align with that.
The documentation overview sections is supposed to provide a map
for the rest of the reference document. The getting help and upgrading
sections were moved to align with that.
Using the revision line means that the revision number is automatically
set. The revision number is then included by the HTML and PDF backends
in the standard location. In the HTML backend that's alongside the
list of authors. In the PDF backend that's on the title page.
Closes gh-26851
Allow groups to be used with standard locations so that order of
profile-specific files is consistent.
Prior to this commit, the default search locations considered for
application properties/yaml files was the following:
optional:classpath:/
optional:classpath:/config/
optional:file:./
optional:file:./config/
optional:file:./config/*/
Each of these locations was independent which could cause confusion
if certain combinations were used. For example, if profile-specific
files were added to `classpath:/` and `classpath:/config/` then the
latter would always override the former regardless of the profile
ordering.
This commit updates `StandardConfigDataLocationResolver` so that a
group of locations can be specified for each item. This allows us to
define the following set of search locations which provide more logical
ordering for profile-specific files
optional:classpath:/;optional:classpath:/config/
optional:file:./;optional:file:./config/;optional:file:./config/*/
Closes gh-26593
Previously, the embedded database connection that would be used
could only be controlled via the classpath. If multiple embedded
database dependencies were present, it wasn't possible to control
the one that the auto-configured would use. It also wasn't possible
to disable auto-configuration of an embedded database.
This commit introduces a new configuration property,
spring.datasource.embedded-database-connection. It can be set to
one of the values of the EmbeddedDatabaseConnection enum to control
the auto-configuration of an embedded database. Setting it to none
will disable the auto-configuration and ensure that an external
database is used instead.
Closes gh-23412
Rework the 'Supported Metrics' documentation to improve consistency
access subsections. Details about the `@Timer` annotation have been
pulled into a new section so that they can be referenced rather than
repeated.
See gh-22217
This commit reworks the initial proposal so that jobs and triggers are
treated as first class concepts.
`/actuator/quartz` now returns the group names for jobs and triggers.
`actuator/quartz/jobs` returns the job names, keyed by the available
group names, while `/actuator/quartz/triggers` does the same for
triggers.
`/actuator/jobs/{groupName}` provides an overview of a job group. It
provides a map of job names with the class name of the job.
implementation
`/actuator/triggers/{groupName}` provides an overview of a trigger
group. There are five supported trigger implementations: cron, simple,
daily time interval, calendar interval, and custom for any other
implementation. Given that each implementation has specific settings,
triggers are split in five objects.
`/actuator/jobs/{groupName}/{jobName}` provides the full details of a
particular job. This includes a sanitized data map and a list of
triggers ordered by next fire time.
`/actuator/triggers/{groupName}/{triggerName}` provides the full details
of a particular trigger. This includes the state, its type, and a
dedicate object containing implementation-specific settings.
See gh-10364
Prior to this commit, some exceptions handled at the controller or
handler function level would:
* not bubble up to the Spring Boot error handling support
* not be tagged as part of the request metrics
This situation is inconsistent because in general, exceptions handled at
the controller level can be considered as expected behavior.
Also, depending on how the exception is handled, the request metrics
might not be tagged with the exception.
This will be reconsidered in gh-23795.
This commit prepares a transition to the new situation. Developers can
now opt-in and set the handled exception as a request attribute. This
well-known attribute will be later read by the metrics support and used
for tagging the request metrics with the exception provided.
This mechanism is automatically used by the error handling support in
Spring Boot.
Closes gh-24028
Previously, the auto-configuration for DataSource initialization and
the properties used to configure it were part of the general
DataSource auto-configuration and properties.
This commit moves the auto-configuration of DataSource initialization
out into a separate top-level auto-configuration class. Similarly,
the properties for configuring DataSource initialization have been
moved from `spring.datasource.*` into `spring.sql.init.*`.
The old initialization-related `spring.datasource.*` properties have
been deprecated but can still be used. When they are used, they new,
separate initialization auto-configuration will back off. In other
words, the initialization related `spring.datasource.*` properties
and the `spring.sql.init.*` properties cannot be used in combination.
Closes gh-25323