Prior to this commit, the SslServerCustomizer would use a Reactor Netty
API that lets users customize the SSL configuration, but later override
some of the choices with defaults.
This commits moves from the new deprecated Reactor Netty API and instead
uses a new variant that builds the defaults and lets developers override
them if they want to.
Fixes gh-25913
Fix package tangle in the actuator endpoint package by relocating a
few classes.
The `Producible` and `ProducibleOperationArgumentResolver` classes have
been moved from `endpoint.annotation` to `endpoint` since they aren't
directly tied to annotations.
The `ApiVersion` class has been moved from `endpoint.http` to
`endpoint` since it needs to implement `Producible` and isn't really
tied to HTTP.
Closes gh-25914
Remove the restriction previously prevented `spring.mvc.servlet.path`
from being combined with a `spring.mvc.pathmatch.matching-strategy`
of `PATH_PATTERN_PARSER`. Spring Framework supports this combination
as of v5.3.4.
See gh-24805
Auto-configure `SessionAutoConfiguration` before
`WebFluxAutoConfiguration` to ensure that the correct
`WebSessionManager` bean is created.
See gh-20970
This commit adds a new `spring.webflux.session.cookie.same-site`
confuguration property that sets the default value for the "SameSite"
attribute in the WebFlux session cookies.
Closes gh-20970
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
Update the `ConfigData` import support to allow individual property
sources to be imported with a higher precedence than profile specific
imports.
Prior to this commit, imported sources would always have a higher
precedence than the file that imported them, but a lower precedence
than any profile-specific variant of the same file.
For example, given an `application.properties` that imports `myconfig`,
the contributor tree would be as follows:
ROOT
+- `application.properties`
| +- myconfig
+- `application-<profile>.properties`
The precedence would be:
1) `application-<profile>.properties`
2) myconfig
3) `application.properties`
This works well for most situations, but can be confusing if import is
for a profile-specific property source. For example:
ROOT
+- `application.properties`
| +- myconfig
| +- myconfig-<profile>
+- `application-<profile>.properties`
Results in the order precedence of:
1) `application-<profile>.properties`
2) myconfig-<profile>
3) myconfig
4) `application.properties`
This means that whilst `myconfig` overrides `application.properties`,
`myconfig-profile` does not override `application-<profile>.properties`.
For this specific situation, the preferable order would be:
1) myconfig-<profile>
2) `application-<profile>.properties`
3) myconfig
4) `application.properties`
To support this alternative ordering a new `PROFILE_SPECIFIC` config
data option has been added. Additionally, options may now be specified
on a per-source basis by using the `PropertySourceOptions` interface.
Fixes gh-25766
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
