Prior to this commit, the parameterized DataBufferFactory was never
actually used when setting up the WebClient for each test. This was due
to an oversight when migrating from JUnit 4 to JUnit Jupiter.
See: https://github.com/reactor/reactor-netty/issues/860
This commit fixes this by converting the existing @BeforeEach method to
a local setup method that is invoked from each
@ParameterizedDataBufferAllocatingTest method.
In addition, in order to avoid the 2 second "quiet period" that is
incurred when destroying the ReactorResourceFactory, this commit moves
the setup and destruction of the ReactorResourceFactory to new
@BeforeAll and @AfterAll methods.
The test instance lifecycle has also been switched to PER_CLASS to avoid
static state in the test class.
This commit reverts b2704e1db6 and
configures the ReactorResourceFactory not to use global resources,
thereby allowing all tests in WebClientDataBufferAllocatingTests to
execute within approximately 2 seconds again on Mac OS.
Prior to this commit, ClassUtils.isPrimitiveOrWrapper() and
ClassUtils.isPrimitiveWrapper() did not return true for Void.class.
However, ClassUtils.isPrimitiveOrWrapper() did return true for
void.class. This lacking symmetry is inconsistent and can lead to bugs
in reflective code.
See: https://github.com/spring-projects/spring-data-r2dbc/issues/159
This commit addresses this by adding an entry for Void.class -> void.class
in the internal primitiveWrapperTypeMap in ClassUtils.
Closes gh-23572
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
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
This commit copies the toEntity and toEntityList methods from
ClientResponse to ResponseSpec, so that it is possible to retrieve
a ResponseEntity when using retrieve().
Closes gh-22368
Prior to this commit, returning an empty mono from an exception handler
registered through ResponseSpec::onStatus would result in memory leaks
(since the response was not read) and in an empty response from bodyTo*
methods of the webclient.
As of this commit, that same empty mono is now interpreted to return
the body (and not an exception), offering a way to override the default
status handlers and return a normal response for 4xx and 5xx status
codes.
