This commit makes sure that reading is enabled after the current
signal has been processed, not while is is being processed. The bug
was only apparent while using the JettyClientHttpConnector, which
requests new elements continuously, even after the end of the
stream has been signalled.
This commit prepends "[{index}] " to all custom display names
configured via @ParameterizedTest.
This provides better diagnostics between the "technical names" reported
on the CI server vs. the "display names" reported within a developer's
IDE.
See gh-23451
This commit polishes tests in spring-aop by using
OrderComparator.sort() and lambda expressions instead of anonymous
classes where feasible.
Closes gh-23458
Prior to this commit, the Spring Framework build would mix proper
framework modules (spring-* modules published to maven central) and
internal modules such as:
* "spring-framework-bom" (which publishes the Framework BOM with all
modules)
* "spring-core-coroutines" which is an internal modules for Kotlin
compilation only
This commit renames these modules so that they don't start with
"spring-*"; we're also moving the "kotlin-coroutines" module under
"spring-core", since it's merged in the resulting JAR.
See gh-23282
Previously DefaultWebClientBuilder always defaulted the ClientHttpConnector
with ReactorClientHttpConnector. This worked fine if reactor was used.
However, it would break if the user was trying to leverage Jetty.
This commit defaults to use Reactory Netty HttpClient if it is present. If
it is not present it then Jetty's HttpClient is used if present.
Closes gh-23491
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests
With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).
See gh-23282
The recently added body(Object) variant can be confused easily with
body(Publisher, Class) forgetting to provide the element type and
only running into the IllegalArgumentException at runtime.
See gh-23212
This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.
This commit also includes the following.
- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
existing JUnit 4 tests in the spring-test module in order to perform
assumptions using JUnit 4's Assume class
See gh-23451
This commit migrates parameterized tests in spring-core using the
"composed @ParameterizedTest" approach. This approach is reused in
follow-up commits for the migration of the remaining modules.
For a concrete example, see AbstractDataBufferAllocatingTests and its
subclasses (e.g., DataBufferTests).
Specifically, AbstractDataBufferAllocatingTests declares a custom
@ParameterizedDataBufferAllocatingTest annotation that is
meta-annotated with @ParameterizedTest and
@MethodSource("org.springframework.core.io.buffer.AbstractDataBufferAllocatingTests#dataBufferFactories()").
Individual methods in concrete subclasses are then annotated with
@ParameterizedDataBufferAllocatingTest instead of @ParameterizedTest or
@Test.
The approach makes the migration from JUnit 4 to JUnit Jupiter rather
straightforward; however, there is one major downside. The arguments
for a @ParameterizedTest test method can only be accessed by the test
method itself. It is not possible to access them in an @BeforeEach
method (see https://github.com/junit-team/junit5/issues/944).
Consequently, we are forced to declare the parameters in each such
method and delegate to a custom "setup" method. Although this is a bit
cumbersome, I feel it is currently the best way to achieve fine grained
parameterized tests within our test suite without implementing a custom
TestTemplateInvocationContextProvider for each specific use case.
Once https://github.com/junit-team/junit5/issues/878 is resolved, we
should consider migrating to parameterized test classes.
See gh-23451
This commit avoids the use of the deprecated
GenericTypeResolver.resolveParameterType() method in tests in order to
avoid warnings in the Gradle build.
Added support for status codes that do not occur in HttpStatus in
DefaultClientResponseBuilder and made ClientResponse::statusCode
ClientHttpResponse::getStatusCode @Nullable.
Closed gh-23366
- Add onRawStatus to WebClient.ResponseSpec, allowing users to deal with
raw status codes that are not in HttpStatus.
- No longer throw an exception status codes not in HttpStatus.
Closes gh-23367
Prior to this commit, the SimpleUrlHandlerMapping classes in Spring MVC
and Spring Webflux only had default constructors. This lead to the fact
that users often had to explicitly invoke setUrlMap() and setOrder() on
the newly instantiated SimpleUrlHandlerMapping.
In order to simplify the programmatic setup of a SimpleUrlHandlerMapping
in common scenarios, this commit introduces the following constructors.
- SimpleUrlHandlerMapping()
- SimpleUrlHandlerMapping(Map<String, ?> urlMap)
- SimpleUrlHandlerMapping(Map<String, ?> urlMap, int order)
Closes gh-23362
Sebastien Deleuze
Arjen Poutsma
康智冬
Sam Brannen
Сергей Цыпанов
lijuny
Rossen Stoyanchev
Brian Clozel
Rob Winch
Stephane Nicoll
Sauhard Sharma
Juergen Hoeller
Stephane Maldini
Johnny Lim