This commit improves CORS support by:
- Using CORS processing only for CORS-enabled endpoints
- Skipping CORS processing for same-origin requests
- Adding Vary headers for non-CORS requests
It introduces an AbstractHandlerMapping#hasCorsConfigurationSource
method in order to be able to check CORS endpoints efficiently.
Closes gh-22273
Closes gh-22496
As of Coroutines 1.2.0-alpha, Dispatchers.Unconfined
is a stable API so we can leverage it in order to get
better performances in our Reactive to Coroutines
bridge.
See gh-19975
The cancellation callback in asynchronousReadFileChannel must be called
before the first read I/O or otherwise if cancellation signals happens
immediately the onDispose callback may be missed.
The DefaultBufferFactory workaround however remains in place until an
expected additional fix arrives with Reactor Core 3.2.9.
See gh-22107
Update `AnnotationUtils` so that `RepeatableContainers.none()` is used
when performing an exhaustive search for merged annotations. These
parameters were accidentally removed in commit 210b1789 and weren't
caught earlier because we were missing a test.
Closes gh-22702
Update `addConventionAnnotationValues` so that `value` attributes
do not override existing annotation values. The aligns the new
`MergedAnnotations` API with the previous `AnnotatedElementUtils`
logic.
Closes gh-22703
Following a response on
https://github.com/reactor/reactor-core/issues/1634 apparently
FluxSink is respecting doOnDiscard but there is a race condition
in DataBufferUtils with file reading.
This commit makes two changes:
1) Add more checks for onDispose to detect cancellation signals
as well as to deal with potentially concurrent such signal.
2) Do not close the channel through the Flux.using callback but
rather allow the current I/O callback to take place and only then
close the channel or else the buffer is left hanging.
Despite this tests still can fail due to a suspected issue in Reactor
itself with the doOnDiscard callback for FluxSink. That's tracked under
the same issue https://github.com/reactor/reactor-core/issues/1634
and for now the use of DefaultDataBufferFactory is enforced as a
workaround until the issue is resolved.
See gh-22107
Prior to this commit, the three `test` tasks in the spring-test module
shared the same output directory for test reports. This had the
negative side effect of causing Gradle to believe that the tasks were
not UP-TO-DATE. Consequently, all three `test` tasks in the spring-test
module were executed for every build even if there were zero changes in
the spring-test module.
This commit fixes this issue by allowing Gradle to use the default test
results output directory for each `test` task. Thanks to @marcphilipp
for providing the tip.
In addition, the Artifactory Gradle task in the Default Job of the
Bamboo build plan for the Spring Framework (SPR-PUB) has been updated
to use the following custom test results directory pattern:
`**/build/test-results/**/*.xml`.
See: https://guides.gradle.org/using-build-cache/#concepts_overlapping_outputs
This commit provides both nullable and non-nullable variants for
awaitBody, makes awaitPrincipal return type nullable and rename
awaitResponse to awaitExchange for better consistency with Java API.
See gh-19975