The attribute was previously removed only before exception resolution
in the DispatcherServlet in order to allow error rendering to make an
independent choice on content negotation.
However, Boot rendering happens later in an ERROR dispatch which could
also be a nested dispatch on some servers. So the attribute must also
generally be removed prior to mapping.
We also move the methods where this is done to the base
RequestMappingInfoHandlerMapping class which also deals with the
produces condition and where the producible attribute is added in the
first place.
Closes gh-24466
Even thought Tomcat and Jetty, which commit the response more lazily,
were not impacted by this issue, it still makes sense for them to
complete the WebFlux response (and pre-commit actions) at the same time
as for other servers for consistent behavior.
See gh-24475
Prior to this commit, spring-aspects would consider spring-orm as a
module providing aspects, which is not the case (anymore).
This commit removes that dependency as a result.
Fixes gh-24491
Prior to this commit, some WebSocket `RequestUpgradeStrategy` reactive
implementations would prevent the application from writing HTTP headers
and cookies to the response.
For Reactor Netty and Undertow, handling the upgrade and starting the
WebSocket communication marks the response status and headers as sent
and the application cannot update HTTP response headers after that.
This commit ensures that the `RequestUpgradeStrategy` implementations
mark the responses as "complete", so that headers are written before we
delegate to the server implementation.
Fixes gh-24475
Spring Framework 5.1.8 introduced a regression for the compilation of
SpEL expressions referencing a method declared in an interface. An
attempt to compile such an expression resulted in a
SpelEvaluationException caused by an IncompatibleClassChangeError.
This commit fixes this regression by adding explicit support in
ReflectivePropertyAccessor.OptimalPropertyAccessor.generateCode() for
methods declared in interfaces.
Closes gh-24357
Setting `options.fork = true` causes the classpath in the forked
compiler process to include Class-Path entries from MANIFEST.MF files
in JARs in the classpath, which results in warnings about missing
classpath entries.
This commit removes the `options.fork = true` declaration and further
simplifies the script.
See gh-24474
Spring Framework 5.0 introduced a regression in ASM-based annotation
processing. Specifically, nested annotations were no longer supported,
and component scanning resulted in an exception if a candidate
component was annotated with an annotation that contained nested
annotations.
This commit fixes this regression by introducing special handling in
AnnotationTypeMapping that supports extracting values from objects of
type TypeMappedAnnotation when necessary.
Closes gh-24375
This is a follow-up on the earlier commit
28a95e89f3 eliminating windowUntil
entirely which generates a BubblingException wrapper. This also keeps
the chain a little simpler.
See gh-24355
This commit makes the Jackson2Tokenizer enable
TokenBuffer.forceUseOfBigDecimal if the element type given to the
Decoder is BigDecimal. Previous to this commit, values would be
converted to floats.
Closes gh-24479
0.4.0 provides built-in support for remembering a user's selections
using local storage. This replaces the custom switch language
JavaScript.
The selection is stored using a key derived from the
options that were available. Concretely, when the options are Java or
Kotlin, the local storage key is java-kotlin. Similarly, if the
choices were Java, Kotlin, and XML, the key would be java-kotlin-xml.
Given local storage's domain and protocol scoping, the nature of the
key that's used for storage will allow a user's selections to be
applied across all documentation hosted on https://docs.spring.io that
offer the same options.
Closes gh-24481
After this commit, Jackson2Tokenizer honours ObjectMapper's
DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS feature when creating
TokenBuffers.
Closes gh-24479
Prior to this commit, the "-Werror" was removed as a command-line
argument in order not to fail the build for missing classpath elements.
This commit reinstates "-Werror" and removes "-Xlink:path" in order to
explicitly ignore warnings for missing classpath elements when executing
the build with a custom JAVA_HOME.
See gh-24474
This commit adds support for the following two JVM system properties
that control the Gradle build for alternative JDKs (i.e., a JDK other
than the one used to launch the Gradle process).
- customJavaHome: absolute path to the alternate JDK installation to
use to compile Java code and execute tests. Setting this system
property causes Groovy 3.0 RC3 to be used instead of 2.5.x. This
system property is also used in spring-oxm.gradle to determine
whether JiBX is supported.
- customJavaSourceVersion: Java version supplied to the `--release`
command line flag to control the Java source and target compatibility
version. Supported versions include 9 or higher. Do not set this
system property if Java 8 should be used.
Examples:
./gradlew -DcustomJavaHome=/opt/java/jdk-14 test
./gradlew --no-build-cache -DcustomJavaHome=/opt/java/jdk-14 test
./gradlew -DcustomJavaHome=/opt/java/jdk-14 -DcustomJavaSourceVersion=14 test
See gh-24474
Qimiao Chen
Sviatoslav Hryb
Rossen Stoyanchev
Hyunjin Choi
Brian Clozel
ZhangT
Juergen Hoeller
Sam Brannen
Andy Wilkinson
Arjen Poutsma
Michael Simons
Stephane Nicoll