This commit replaces the Mockito agent configuration with a single
bytebuddy agent configuration that addresses both Mockito and mockk on
tests.
Closes gh-35207
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
Deploy Docs / Dispatch docs deployment (push) Waiting to runDetails
MethodBasedEvaluationContext and CacheEvaluationContext should allow a
nullable rootObject constructor parameter like
StandardEvaluationContext does.
Closes gh-35206
While assessing #35195, I noticed the following issues with our
Checkstyle configuration regarding nullability annotations.
- "^(?!org\.jspecify|\.annotations).*(NonNull|Nullable)$" contains a "|".
- "^(?!org\.jspecify|\.annotations).*(NonNull|Nullable)$" matches against
NonNull but not against Nonnull, and therefore incorrectly permits
usage of javax.annotation.Nonnull.
- Some of the Checkstyle suppressions no longer apply.
This commit addresses all of the above issues and updates several tests
to use example annotations other than javax.annotation.Nonnull where
feasible.
See gh-35195
Closes gh-35205
As of #33894, `HttpMessageConverters` auto-detects converters and use
custom-provided ones to configure a collection of converters for the
client or the server.
Right now the multipart converter is only configured if core converters
(JSON, XML...) are configured/detected. We do not reuse the base
converters (resource, string, byte array) for the multipart converter
as it applies different encoding defaults (ISO for the main ones, UTF-8
for multipart).
This commit refines the configuration to not only include the multipart
converter when core converters are present, but also if any other
converter was configured.
Closes gh-35203
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
Deploy Docs / Dispatch docs deployment (push) Waiting to runDetails
Since the introduction of the Spring TestContext Framework in 2007,
application contexts have always been stored in the context cache in a
"running" state. However, leaving a context running means that
components in the context may continue to run in the background. For
example, JMS listeners may continue to consume messages from a queue;
scheduled tasks may continue to perform active work, etc.; and this can
lead to issues within a test suite.
To address such issues, this commit introduces built-in support for
pausing application contexts when they are not in use and restarting
them if they are needed again.
Specifically, the TestContextManager now marks a test's application
context as "unused" after execution of the test class has ended, and
the underlying ContextCache then "stops" the application context if no
other test class is currently using the context. When a
TestExecutionListener later attempts to obtain a paused application
context -- for example, for a subsequent test class that shares the
same application context -- the ContextCache ensures that context is
restarted before returning it.
See https://github.com/spring-projects/spring-boot/issues/28312
See gh-35171
Closes gh-35168
Prior to this commit, ApplicationContextEvent inherited getSource()
from java.util.EventObject.getSource() which has an Object return type.
This commit introduces a local getSource() implementation in
ApplicationContextEvent with an ApplicationContext covariant return
type, analogous to TestContextEvent in spring-test.
Closes gh-35197
Prior to this commit, there was no way to differentiate between an
ApplicationContext "start" and "restart" in terms of events. This was
due to the fact that a ContextStartedEvent was fired for both
AbstractApplicationContext.start() and
AbstractApplicationContext.restart().
To assist developers who may wish to differentiate between "start" and
"restart" events, this commit introduces a new ContextRestartedEvent as
a subtype of ContextStartedEvent. In addition,
AbstractApplicationContext.restart() now publishes a
ContextRestartedEvent instead of a ContextStartedEvent.
By making ContextRestartedEvent a subtype of ContextStartedEvent,
applications can still expect ContextStoppedEvent/ContextStartedEvent
event pairs for consistent lifecycle semantics, and they can optionally
check if the ContextStartedEvent is a ContextRestartedEvent.
Alternatively, applications can explicitly react to a
ContextRestartedEvent.
See gh-35168
See gh-35171
Closes gh-35194
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
Deploy Docs / Dispatch docs deployment (push) Waiting to runDetails
As of #33894, we introduced a new `HttpMessageConverters` API.
While this achieved our goal of focusing converters classpath detection
in a single place and avoiding waste, a single `HttpMessageConverters`
instance for both client and server added more complexity for developers.
This commit aligns the API here with the WebFlux `CodecsConfigurer` to
opt for a client/server flavor as the first step in the builder.
While this make the sharing of converter instances between server and
client impossible, this allows for a simpler API and separates concerns.
Closes gh-35187
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:23], map[id:ubuntu-latest name:Linux]) (push) Waiting to runDetails
Deploy Docs / Dispatch docs deployment (push) Waiting to runDetails
Prior to this commit, subclasses of AbstractBeanFactoryBasedTargetSource
referenced the targetBeanName via getTargetBeanName() which throws an
IllegalStateException if the targetBeanName has not yet been set.
This commit changes the visibility of the targetBeanName field from
private to protected in order to facilitate direct access through
this.targetBeanName where no assertion is needed.
By doing so, we avoid exceptions in logging and toString()
implementations in subclasses.
Closes gh-35172
Signed-off-by: chenggwang <90715678+chenggwang@users.noreply.github.com>
Co-authored-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>