This commit introduces support for tracking operations during SpEL
expression evaluation. If the maximum number of operations is exceeded,
a SpelEvaluationException is thrown.
The limit can be configured either on a per-use-case basis via
SpelParserConfiguration supplied to the SpelExpressionParser or
globally as a JVM system property or Spring property named
`spring.expression.maxOperations`.
Closes gh-36801
This commit updates the default view name generation logic in
both Spring WebMVC and Spring WebFlux to prevent "redirect:"
and "forward:" (for MVC) prefixes from the incoming request path.
Closes gh-36793
This commit introduces trusted packages, specified via the related
setter for untrusted use cases. It allows explicit configuration
of which Java packages are allowed to be deserialized.
Closes gh-36791
This commit introduces trusted packages, specified via the related
setter for untrusted use cases. It allows explicit configuration
of which Java packages are allowed to be deserialized.
See gh-36791
CronTrigger carries an optional ZoneId since 5.3 that affects
nextExecution; however, prior to this commit, equals() and hashCode()
only considered the cron expression.
This commit ensures that CronTrigger instances with the same cron
expression but different time zones are no longer considered equal.
Closes gh-36871
Signed-off-by: zhaomeng <zhaomeng1.vendor@sensetime.com>
The links to docs.seleniumhq.org no longer resolve, since the host was
retired.
This commit changes those links to use the current Selenium
documentation at selenium.dev.
Closes gh-36875
Signed-off-by: leestana01 <leestana01@naver.com>
getClassName now calls ClassReader.getClassName() directly instead
of routing through the visitor-based getClassInfo. Previously, it
allocated a List and a ClassVisitor and decoded super_class and
every interface name only to discard all but the first element.
The method is on the hot path of every CGLIB proxy class definition,
so this change significantly lowers its per-call processing cost.
Closes gh-36814
Signed-off-by: cookie-meringue <daehyeon3351@gmail.com>
This commit adds further fixes in the same area, since there were
similar bugs in the WriteCompletionHandler:
* databuffers were not always emitted when fully read in the onNext hook
* on completion, the iterator was closed too early, before it was fully
read
* on completion, writing the next bytebuffers from the iterator would
always reuse the first one and not update the attachment
Closes gh-36714
Prior to this commit, WritableByteChannelSubscriber.hookOnNext() called
iterator.next() exactly once. If a DataBuffer consisted of multiple NIO
ByteBuffers (e.g., NettyDataBuffer wrapping a CompositeByteBuf), only
the first buffer was written to the channel, and the remaining buffers
were silently ignored and lost.
This commit adds the missing while (iterator.hasNext()) outer loop to
ensure all fragmented buffers exposed by the iterator are completely
and safely written to the synchronous channel.
See gh-36714
Signed-off-by: KimDaehyeon <daehyeon3351@gmail.com>
A disconnected client error does not necessarily prevent us from setting
the status of the WebFlux ServerHttpResponse, which is only gated by a
committed flag and does not necessarily reflect the connection state.
This is why we need to check if we have a disconnected client error
first and handle it accordingly. We still set the response to 500
in case the disconnect client error is to a remote host in which
case it will propagate to the client.
Closes gh-36811
DisconnectedClientHelper identifies lost connection issues, but it's
not always easy to know if it is the connection to the client or to
another remote host. DisconnectedClientHelper does recognize and
filter out common client exceptions, but there is a possibility for
other similar custom exceptions.
DefaultHandlerExceptionResolver now attempts to set the status to
500, which won't impact a client that has gone away, but it will
set the status correct on the off chance that the exception is
actually a server side issue.
Closes gh-34481
This fixes a potential regression introduced by the previous commit.
Because the current value was not updated after the temporal was rolled
forward, there were new cases where entire days would be skipped.
Closes gh-36865
After rollForward, BitsCronField always searched for the next
matching bit from zero. When daylight saving creates a gap at
the start of a period (e.g. Africa/Cairo), the temporal lands on
a non-zero field value and matching from zero could advance an
entire period too far, skipping the calendar day.
Search from the actual field value in the new period instead,
falling back to zero only when no bit matches in that period.
See gh-36865
Signed-off-by: arno <me@zmovo.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
The detectNumberOfBuffers() method attempted to scale the read
buffer count based on the number of available processors, but used
Math.min(4, nextPowerOfTwo) which effectively caps the result at 4
regardless of CPU count. For systems with fewer than 3 processors,
the buffer count would be reduced below 4, but this edge case adds
complexity without measurable benefit.
Simplify BUFFER_COUNT to a constant value of 4, removing the
unnecessary CPU-detection logic.
Closes gh-36872
Signed-off-by: seungchan <s24041@gsm.hs.kr>
Prior to this commit, comments sent with Server Sent Events could break
the wire format when sent over the network when comments contained line
breaks.
While comments are mainly used for sending keepalive messages, they can
also be used for sending debug data. This commit ensures that line
breaks are properly handled in comments.
Fixes gh-36866
DataBinder applies its auto-grow collection limit to bean
property access, but direct field access left DirectFieldAccessor
at its default limit.
Pass DataBinder's configured limit into DirectFieldBindingResult
and apply it to the DirectFieldAccessor.
Closes gh-36861
Signed-off-by: Matthias Kurz <m.kurz@irregular.at>
awaitEntity() used T::class.java which erases generic type
information (e.g. List<Foo> becomes just List). Use the
reified toEntity<T>() extension instead, which preserves
full generic type via ParameterizedTypeReference.
Closes gh-36834
Signed-off-by: wushiyuanmaimob <wushiyuanwork@outlook.com>
When parsing a relative URI such as `path2#foo`, RfcUriParser's
SCHEME_OR_PATH state advanced to FRAGMENT without moving the component
index past the `#` character, so the captured fragment included the
entire input (`path2#foo`) instead of just `foo`. As a result,
`toUriString()` produced `path2#path2#foo`.
Update the SCHEME_OR_PATH `#` transition to advance the component
index to `i + 1`, matching the sibling `?` -> QUERY transition in the
same state and every other `-> FRAGMENT` transition in the parser.
URIs with a `/` in the path are unaffected because they leave
SCHEME_OR_PATH for PATH on the first slash; the WhatWG parser already
handled this case correctly.
Closes gh-36762
Signed-off-by: daguimu <daguimu.geek@gmail.com>
Prior to this commit, the `antora` Gradle task silently failed to build
the reference documentation, since Antora uses the latest LTS release
for Node.js by default, and the latest LTS apparently does not work for
us.
Prior to this commit, MIME type parsing in Spring would allow duplicate
parameters like "text/plain; dupe=1; dupe=2", effectively retaining the
latest value and ignoring the first.
RFC 6838 4.3 states that this should be treated as an error and this
commit ensures that this is the case.
Closes gh-36841
Add a public accessor for the ClassLoader configured on a
DefaultDeserializer instance so that callers no longer need to read the
private field via reflection in order to forward it to a
ConfigurableObjectInputStream subclass.
See gh-36827
Closes gh-36833
Signed-off-by: seonwoo_jung <laborlawseon@kap.kr>
Prior to this commit, gh-36328 avoided using RFC 2047 encoding for the
"filename" parameter and use ISO-8859-1 only. This change unfortunately
caused issues because some implementations might try and detect the
encoding automatically.
This commit restricts the filename parameter to ASCII encoding only by:
* transliterating characters to the closes ASCII character
("é"->"e", "ä"->"ae"...)
* falling back to "_" for other chacacters with non latin alphabet or
emojis
Fixes gh-36805
Prior to this commit, it was not possible to specify the character set
to use with ExchangeFilterFunctions#basicAuthentication.
To address that, this commit introduces a new
Closes gh-36777
Signed-off-by: Kai Zander <61500114+kzander91@users.noreply.github.com>
Prior to this commit,
MicrometerObservationRegistryTestExecutionListener always attempted to
load the test's ApplicationContext in order to update the
ObservationThreadLocalAccessor in its beforeTestMethod() callback, even
if there was no active ApplicationContext.
To avoid unnecessarily loading an ApplicationContext or attempting to
load an ApplicationContext that cannot be loaded (for example, due to a
context-load failure), this commit applies a hasApplicationContext()
check in beforeTestMethod().
Since the MicrometerObservationRegistryTestExecutionListener is
registered after the DependencyInjectionTestExecutionListener (at least
by default), an active ApplicationContext should be present unless
dependency injection from the context failed or the context failed to
load.
Closes gh-36817
Prior to this commit and the previous commit,
MockitoResetTestExecutionListener always attempted to load the
ApplicationContext to reset mocks in its beforeTestMethod() and
afterTestMethod() callbacks, even if there was no active
ApplicationContext.
The reason this was noticed is that the @BeforeMethod(alwaysRun = true)
and @AfterMethod(alwaysRun = true) lifecycle methods in
AbstractTestNGSpringContextTests are always invoked, even if a previous
lifecycle configuration method failed (for example, due to a
context-load failure).
However, with JUnit Jupiter and the SpringExtension the
beforeTestMethod() and afterTestMethod() callbacks in the
TestExecutionListener API are not invoked if there was a previous
lifecycle failure.
Consequently, the reported drawbacks only exist when using Spring's
TestNG base support classes
This commit picks up where the previous commit left off by applying the
same hasApplicationContext() check in beforeTestMethod().
This commit also introduces unit and integration tests for both Jupiter
and TestNG support.
Closes gh-36782
Avoid using String#replaceAll when the pattern is not a regular
expression.
Using java.lang.String#replace(CharSequence, CharSequence) will
improve performance.
Closes gh-36678
Signed-off-by: shenjianeng <ishenjianeng@qq.com>
Prior to this commit, MIME types with parameter values that contain a
quoted pair would sometimes fail and parse an incomplete parameter
value.
This commit ensures that the quoted section of the parameter value is
correctly handled.
Fixes gh-36730
Prior to this commit, the `resolveUrlPath` implementation for the
`LiteWebJarsResourceResolver` would always delegate to the resource
chain once the versioned webjar folder has been resolved.
While this aligns with the `ResourceResolver` contract and the fact that
the resource chain does not resolve directories, here the WebJar locator
does support such use cases and we shouldn't get in the way here.
This commit falls back to the resolved versioned WebJar path if no
resource could be resolved and the path ends with "/".
Fixes gh-36726
StompBrokerRelayMessageHandler only set the host header in CONNECT
frames when virtualHost was explicitly configured. Per STOMP 1.2, the
host header is required on CONNECT frames.
Fall back to relayHost (the TCP connection target) when virtualHost is
not configured, ensuring the host header is always present in both
system session and client session CONNECT frames.
Closes gh-36673
Signed-off-by: cuitianhao <54015884+tianhaocui@users.noreply.github.com>
Prior to this commit, the `PartGenerator` would allow requesting
additional part tokens while in the `CreateFileState`. This is invalid
as any new token emitted would be rejected and would fail the entire
process.
This would only happen if the tmp file creation is slow enough for a new
token to be parsed and emitted.
This commit ensures that no new part token is requested while creating
the temporary file.
This change also fixes lifecycle issues and ensures that buffer
resources are cleaned in case of errors.
Fixes gh-36694
Prior to this commit, thread-local variables like Trace ID were not
automatically propagated into the Reactor Context when making requests
using Kotlin coroutine WebClient extensions like `awaitExchange`.
This commit updates `CoroutineContext.toReactorContext()` to capture
thread-local values via Micrometer Context Propagation when available,
ensuring observations and traces are properly reused.
Closes gh-36182
This commit fixes a regression introduced by gh-36449 for
nullable value class with an non-null value.
Closes gh-36665
Signed-off-by: Sigurd Gerke <sigurd.gerke@onedata.de>
Prior to this commit, there could be cache collisions in the
`CachingResourceResolver` because the cache key generation was
incomplete. This commit expands the cache key generation to avoid such
cases.
Fixes gh-36713
Prior to this commit, content based version strategies would remove all
instances of the version string in the request path when trying to
resolve the original resource with the chain.
This can cause issues in rare cases where there is a collision between
the content version and some other version string in the request path.
Because this strategy is based on the contents of the file itself, we
should only remove the last instance of the version string and then
attempt to resolve the original file.
Fixes gh-36698
As of gh-36692, Spring logs a WARN message when an unsafe resource
handling location is configured. This change now rejects entirely such
setups by failing before the application starts up.
Closes gh-36695
Prior to this commit, `ResourceHandlerUtils` would perform resource
location checks to ensure that the configured location is valid. This
commit also ensures that we log a WARN message if the application
chooses a well-known unsafe location like "classpath:" or the root
Servlet context for serving static resources.
Closes gh-36692
Prior to this commit, WebClientUtils.getRequestDescription()
created a new URI object on every invocation. Since the URI
constructor includes validation and parsing, which is already
performed by the parameter URI object, this was unnecessarily
expensive for a logging utility.
This commit reuses the original URI's string representation
to avoid redundant parsing.
This commit also strips userInfo, query, and fragment from the
log description even if URIs contain only userInfo or
fragment (without a query).
Closes gh-36641
Signed-off-by: 박동윤 (Park Dong-Yun) <ehddbs7458@gmail.com>
This commit reverts the changes made to WebDataBinder's doBind()
implementation in e4d03f6625 and instead implements the skipping logic
directly in checkFieldDefaults(), checkFieldMarkers(), and
adaptEmptyArrayIndices() by preemptively checking if the corresponding
field is allowed.
This commit also improves the Javadoc and adds missing tests.
Fixes gh-36625
In Spring Framework 7.0, we introduced support for using `Optional`
with the null-safe and Elvis operators in SpEL expressions; however,
such expressions were previously not compilable.
To address that, this commit introduces a new
insertOptionalUnwrapIfNecessary() method in CodeFlow which effectively
inserts byte code instructions for `myOptional.orElse(null)`, and the
Elvis, Indexer, MethodReference, and PropertyOrFieldReference
implementations have been modified to track the need to unwrap an
`Optional` in compiled mode and delegate to
insertOptionalUnwrapIfNecessary() accordingly.
See gh-20433
See gh-36331
Closes gh-36330
HttpMethod.valueOf() performs a case-sensitive lookup of predefined
HttpMethod constants. For example, valueOf("GET") resolves to
HttpMethod.GET, whereas valueOf("get") results in a newly created
HttpMethod instance.
Update the Javadoc to explicitly document this behavior.
See gh-36642
Closes gh-36652
Signed-off-by: angry-2k <edkev@kakao.com>
This commit moves the JSON specific code to
KotlinSerializationJsonDecoder, uses switchOnFirst operator to keep the
existing behavior and derives the list serializer from the element one.
Closes gh-36597
Prior to this commit, the implementation of HttpMethod.valueOf()
aligned with the semantics of Enum#valueOf() which requires an exact
match for the enum constant name.
However, since HttpMethod is no longer an enum, that restriction is no
longer necessary. Consequently, this commit revises the implementation
of valueOf() to perform a case-insensitive lookup for predefined
constants.
In other words, HttpMethod.valueOf("GET") and HttpMethod.valueOf("get")
now both resolve to HttpMethod.GET.
Closes gh-36518
The Spring TestContext Framework does not honor the
`spring.profiles.active` system property when determining
active profiles for a test class if @ActiveProfiles is
used.
This commit documents that behavior in the @ActiveProfiles
and DefaultActiveProfilesResolver Javadoc, as well as in
the reference manual. A SystemPropertyActiveProfilesResolver
example is also added showing how to allow
`spring.profiles.active` to override @ActiveProfiles.
See gh-36269
Closes gh-36600
Signed-off-by: Mohak Nagaraju <98132980+Mohak-Nagaraju@users.noreply.github.com>
Prior to this commit, fields that are not allowed for binding were
always skipped and would not be bound. But the field and default marker
support (with the "_" and "!" prefixes) would be still considered and
could trigger collection instantiation/autogrow.
While this does not cause unwanted binding, this allocates memory for no
reason. This commit revisits the binding algorithm to only consider
default and field marker support if the regular field is allowed.
Fixes gh-36625
Prior to this commit, SqlScriptsTestExecutionListener unwrapped data
sources wrapped in an InfrastructureProxy or a scoped proxy, but it did
not unwrap a data source wrapped in a TransactionAwareDataSourceProxy.
Consequently, the sameDataSource() check failed in the latter case,
preventing execution of @Sql scripts.
To address that, this commit revises sameDataSource() to unwrap a
TransactionAwareDataSourceProxy as well, analogous to the
implementations of setDataSource() in DataSourceTransactionManager,
JpaTransactionManager, and HibernateTransactionManager.
Closes gh-36611
Use defensive Date copies for sentDate to avoid shared mutable state.
Apply consistent handling in setSentDate, getSentDate, the copy constructor, and copyTo.
Add regression tests for mutation safety and copy isolation.
Closes gh-36626
Signed-off-by: Junseo Bae <ferrater1013@gmail.com>
Use `CollectionUtils::newLinkedHashSet` instead of `LinkedHashSet::new` to avoid resizing.
Closes gh-36618
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
We currently have three implementations of MethodMetadata:
- StandardMethodMetadata (Java reflection)
- SimpleMethodMetadata (ASM)
- ClassFileMethodMetadata (ClassFile API)
The ASM and ClassFile variants return a string equivalent to
Class#getTypeName(); whereas, StandardMethodMetadata currently returns a
binary name using Class#getName() (for example, `[I` instead of `int[]`).
In order to align with the ASM and ClassFile variants and provide
consistent results for all MethodMetadata implementations, this commit
revises StandardMethodMetadata.getReturnTypeName() to use
Class#getTypeName().
Closes gh-36619
Prior to this commit, the `return` keyword was missing in
TypeMappedAnnotation's getClassLoader() implementation, which prevented
the ClassLoader of the Member (Method or Field) from being used.
This commit fixes that by adding the missing `return` keyword and adds
a test using a custom ClassLoader to verify the correct behavior.
Closes gh-36606
ProfilesParser.parseTokens() silently accepts unbalanced parentheses
in profile expressions such as "dev)" or "(dev", treating them as
valid. This can lead to unexpected behavior where malformed @Profile
annotations are silently interpreted instead of being rejected.
This commit tightens the validation in parseTokens() to reject:
- Unmatched closing parenthesis at the top level
- Unmatched opening parenthesis when tokens are exhausted
Also fixes an existing test that inadvertently relied on this lenient
behavior by using "spring&framework)" instead of "(spring&framework)".
Closes gh-36550
Signed-off-by: daguimu <daguimu.geek@gmail.com>
Prior to this commit, we invoked `Class.getName()` when building error
messages during annotation processing, resulting in exceptions like the
following which use binary names for nested types and arrays.
Attribute 'chars' in annotation
org.springframework.core.annotation.AnnotationUtilsTests$CharsContainer
should be compatible with [C but a [I value was returned
This commit switches to canonical names in error messages in annotation
processing, resulting in improved such errors messages such as the
following.
Attribute 'chars' in annotation
org.springframework.core.annotation.AnnotationUtilsTests.CharsContainer
should be compatible with char[] but a int[] value was returned
In addition, this commit introduces a new getCanonicalName(Class) method
in ClassUtils, which has effectively been extracted from the following
classes where this functionality was previously duplicated.
- AttributeMethods
- SynthesizedMergedAnnotationInvocationHandler
- TypeDescriptor
- DefaultRetryPolicy
- ReflectiveIndexAccessor
Closes gh-36607
Prior to this commit, ClassFileAnnotationDelegate created
MergedAnnotations from a HashSet, which resulted in a non-deterministic
iteration order and lost the original source declaration order of the
annotations.
To address that, this commit revises ClassFileAnnotationDelegate to
create MergedAnnotations from a List.
In addition, this commit updates all related tests to use the
containsExactly() assertion instead of containsExactlyInAnyOrder() to
ensure we consistently adhere to the "source declaration order"
requirement.
Closes gh-36598
Prior to this commit, we used ClassUtils.resolveClassName() in
TypeMappedAnnotation.adapt(...) which throws an IllegalStateException
or IllegalArgumentException if a type referenced by an annotation
attribute cannot be loaded. However, if such an error occurs while
using the JDK's reflection APIs, a TypeNotPresentException is thrown
instead.
In order to align with the standard behavior of the JDK, this commit
modifies TypeMappedAnnotation.adapt(...) to use ClassUtils.forName()
and throw a TypeNotPresentException in such scenarios.
This commit also makes similar changes in
MergedAnnotationReadingVisitor and ClassFileAnnotationDelegate.
Closes gh-36593
Spring Framework 5.2 introduced a regression in our annotation
processing support when the MergedAnnotations API was introduced.
Consequently, prior to this commit, our "annotation attributes as a Map
or AnnotationAttributes instance" support no longer stored exceptions
thrown while attempting to load a type referenced by an annotation
attribute. Instead, the exception was thrown immediately.
To address that, this commit revises our MergedAnnotation.asMap()
support so that it now tracks such exceptions in the map instead of
immediately throwing them. This allows map functionality such as
contains(attributeName), keySet(), etc. to continue to function
properly. In addition, the internal getRequiredAttribute() method in
AnnotationAttributes once again properly throws the original exception
wrapped in an IllegalArgumentException whenever a caller invokes one of
the convenience methods such as getClass() and getClassArray().
Note that this affects both asMap() variants as well as
asAnnotationAttributes().
In addition, this commit reverts the fix applied in 00fbd91cca since
it is no longer necessary.
See gh-36524
Closes gh-36586
Prior to this commit, AnnotationBeanNameGenerator failed when searching
for a convention-based bean name, if an annotation referenced a
non-existent class.
To address that, this commit introduces a try-catch block around each
invocation of MergedAnnotation.asAnnotationAttributes() and skips
processing of the current MergedAnnotation if an exception occurs,
which is likely due to a type referenced from an annotation attribute
not being present in the classpath.
See gh-31203
Closes gh-36524
Revise the BeanRegistrar Javadoc to document the two distinct usage
modes: @Configuration/@Import and programmatic GenericApplicationContext
setup.
Clarify that implementations are not Spring components (requiring a
no-arg constructor and no dependency injection), and detail the ordering
guarantees for each mode.
Add missing tests
Signed-off-by: Stéphane Nicoll <stephane.nicoll@broadcom.com>
Prior to this commit, the ClassFile variant for annotation and method
metadata would report incorrect metadata for:
* the method return type names in case of primitives and array types
* `toString` values for methods
* `equals` and `hashcode` information for methods
This commit expands the test suite and ensures that the ASM and
ClassFile variants are aligned.
Fixes gh-36577
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
Return correct names for primitive and array types
Introduce resolveTypeName helper for ClassDesc handling
Add ClassFileMethodMetadataTests (java24Test)
Extend AbstractMethodMetadataTests with void return case
See gh-36577
Signed-off-by: Junseo Bae <ferrater1013@gmail.com>
GenericApplicationContext-registered BeanRegistrars are invoked after other programmatic bean definitions. Configuration-imported BeanRegistrars participate in configuration class order and in particular in Boot's auto-configuration ordering.
Closes gh-21497
Prior to this commit, all `with**Converter` methods in
`HttpMessageConverters` builders would only apply if the
`registerDefaults()` option is on. While the original intent is to allow
overrides for auto-detected defaults, this creates an unnecessary
discrepancy with `addCustomConverter` which is always effective.
Allowing sich registrations when defaults are off should not introduce
invalid states and only reflects the intent of the developer. This
commit now allows such cases.
Fixes gh-36579
Since commit 89391fd94c, the getClassAttributeWhenUnknownClass() methods
in SimpleAnnotationMetadataTests and DefaultAnnotationMetadataTests
have failed in Eclipse, since the JSR-305 JAR is always on the test
runtime classpath in Eclipse.
To address that, this commit introduces a FilteringClassLoader in both
test classes which mimics the test runtime behavior in the Gradle build.
See gh-36432
`RestTemplate` is deprecated, this commit amends the JavaDoc to mention
its scheduled removal for the next major version, Spring Framework 8.0.
See gh-36574
Prior to this commit, the `RestTestClient` MockMvc integration would
support transforming client requests into MockMvc requests.
`RestTestClient` can serialize `MultiValueMap` request bodies as
multipart requests. In this case, the `MockMvcClientHttpRequestFactory`
would only read the body as byte stream and would not turn this into a
proper `MockMultipartHttpServletRequestBuilder`.
This commit uses the new `MultipartHttpMessageConverter` to parse the
request payload as `MockPart` instances to be added to the MockMvc
requests.
Closes gh-35569
CacheAspectSupport currently contains a protected methodIdentification()
method which is not used internally within the framework, and it appears
that it was accidentally copied from TransactionAspectSupport when the
caching support was first introduced.
In light of that, this commit deprecates it for removal in 7.1.
Closes gh-36576
Prior to this commit, thread-local variables like Trace ID were not
automatically propagated into the Reactor Context when making requests
using Kotlin coroutine WebClient extensions like `awaitExchange`.
This commit updates `CoroutineContext.toReactorContext()` to capture
thread-local values via Micrometer Context Propagation when available,
ensuring observations and traces are properly reused.
Closes gh-36182
As announced in "the state of HTTP clients in Spring" blog post
(https://spring.io/blog/2025/09/30/the-state-of-http-clients-in-spring),
the deprecation timeline for `RestTemplate` was announced last November
and docs were updated accordingly.
This commit `@Deprecate` `RestTemplate` and related types for removal to
send a stronger signal to our community.
The actual removal is scheduled for Spring Framework 8.0 (not yet
scheduled).
Closes gh-36574
Now that `RestClient` offers a better alternative, this commit revisits
our integration tests to use `RestClient` instead of `RestTemplate`.
Closes gh-36573
Prior to this commit, `MockRestServiceServer` would provide
`createServer` shortcuts for `RestTemplate` and `RestGatewaySupport`.
Now that `RestClient` offers a modern client variant, we should provide
the same for `RestClient`.
Closes gh-36572
Prior to this commit, the `SockJsClient` would use the
`RestTemplateXhrTransport`. `RestClient` is a modern replacement for
RestTemplate and should be used instead.
This commit introduces the `RestClientXhrTransport` variant as an
immediate replacement.
Closes gh-36566
Prior to this commit, @MockitoBean and @MockitoSpyBean could be
declared on fields or at the type level (on test classes and test
interfaces), but not on constructor parameters. Consequently, a test
class could not use constructor injection for bean overrides.
To address that, this commit introduces support for @MockitoBean and
@MockitoSpyBean on constructor parameters in JUnit Jupiter test
classes. Specifically, the Bean Override infrastructure has been
overhauled to support constructor parameters as declaration sites and
injection points alongside fields, and the SpringExtension now
recognizes composed @BeanOverride annotations on constructor
parameters in supportsParameter() and resolves them properly in
resolveParameter(). Note, however, that this support has not been
introduced for @TestBean.
For example, the following which uses field injection:
@SpringJUnitConfig(TestConfig.class)
class BeanOverrideTests {
@MockitoBean
CustomService customService;
// tests...
}
Can now be rewritten to use constructor injection:
@SpringJUnitConfig(TestConfig.class)
class BeanOverrideTests {
private final CustomService customService;
BeanOverrideTests(@MockitoBean CustomService customService) {
this.customService = customService;
}
// tests...
}
With Kotlin this can be achieved even more succinctly via a compact
constructor declaration:
@SpringJUnitConfig(TestConfig::class)
class BeanOverrideTests(@MockitoBean val customService: CustomService) {
// tests...
}
Of course, if one is a fan of so-called "test records", that can also
be achieved succinctly with a Java record:
@SpringJUnitConfig(TestConfig.class)
record BeanOverrideTests(@MockitoBean CustomService customService) {
// tests...
}
Closes gh-36096
Prior to this commit, one could invoke
ResolvableType.forMethodParameter(MethodParameter.forParameter(parameter))
to create a ResolvableType for a Parameter; however, that's slightly
cumbersome.
To address that, this commit introduces ResolvableType.forParameter(),
analogous to existing convenience factory methods in ResolvableType.
Closes gh-36545
Since equivalent Assert.notNull() checks are already performed by
subsequent code (constructors and factory methods), there is no need
to perform the exact same assertion twice in such use cases.
Closes gh-36544
This commit adds integration tests and reference documentation
for multipart support in `RestClient` and `RestTestClient`.
Closes gh-35569
Closes gh-33263
Prior to this commit, the `FormHttpMessageConverter` would only support
`MultiValueMap` payloads for reading and writing. While this can be
useful when web forms contain multiple values under the same key, this
prevent developers from using a common `Map` type and factory methods
like `Map.of(...)`.
This commit relaxes constraints in `FormHttpMessageConverter` and
ensures that `Map` types are supported for reading and writing URL
encoded forms.
Note that when reading forms to a `Map`, only the first value for each
key will be considered and other values will be dropped if they exist.
Closes gh-36408
Prior to this commit, gh-36255 introduced the new
`MultipartHttpMessageConverter`, focusing on multipart message
conversion in a separate converter. The `FormHttpMessageConverter` did
conflate URL encoded forms and multipart messages in the same converter.
With the introduction of the new converter and related types in the same
package (with `Part`, `FormFieldPart` and `FilePart`), we can now
revisit this arrangement.
This commit restricts the `FormHttpMessageConverter` to URL encoded
forms only and as a result, changes its implementation to only consider
`MultiValueMap<String, String>` types for reading and writing HTTP
messages. Because type erasure, this converter is now a
`SmartHttpMessageConverter` to get better type information with
`ResolvableType`.
As a result, the `AllEncompassingFormHttpMessageConverter` is formally
deprecated and replaced by the `MultipartHttpMessageConverter`, by
setting part converters explicitly in its constructor.
Closes gh-36256
Prior to this commit, the `FormHttpMessageConverter` would write, but
not read, multipart HTTP messages. Reading multipart messages is
typicaly performed by Servlet containers with Spring's
`MultipartResolver` infrastructure.
This commit introduces a new `MultipartHttpMessageConverter` that copies
the existing feature for writing multipart messages, borrowed from
`FormHttpMessageConverter`. This also introduces a new `MultipartParser`
class that is an imperative port of the reactive variant, but keeping it
based on the `DataBuffer` abstraction. This will allow us to maintain
both side by side more easily.
This change also adds new `Part`, `FilePart` and `FormFieldPart` types
that will be used when converting multipart messages to
`MultiValueMap<String, Part>` maps.
Closes gh-36255
The `AbstractHttpMessageConverter#supportsRepeatableWrites`
contract is a protected method that message converters can override.
This method tells whether the current converter can write several
times the payload given as a parameter. This is mainly useful on the
client side, where we need to know if we can send the same HTTP
message again, after receiving an HTTP redirect status.
Because this method is protected, this limits our ability to call
it from a different package; this is needed for gh-33263.
This commit promotes this method to the main `HttpMessageConverter`
interface and deprecates the former.
Closes gh-36252
Prior to this commit, `SseServerResponse.send()` would flush the
output stream returned by `getBody()`. Since gh-36385,
`ServletServerHttpResponse` wraps this stream with a non-flushing
decorator to avoid performance issues with `HttpMessageConverter`
implementations that flush excessively. As a result, SSE events were
no longer flushed to the client.
This commit changes `send()` to call `outputMessage.flush()` instead
of `body.flush()`, which properly delegates to the servlet response
`flushBuffer()` and is not affected by the non-flushing wrapper.
Fixes gh-36537
The resolveDependency() utility method in ParameterResolutionDelegate
resolves a dependency using the name of the parameter as a fallback
qualifier. That suffices for most use cases; however, there are times
when a custom parameter name should be used instead.
For example, for our Bean Override support in the Spring TestContext
Framework, an annotation such as @MockitoBean("myBean") specifies an
explicit name that should be used instead of name of the annotated
parameter.
Furthermore, introducing support for custom parameter names will
greatly simplify the logic in SpringExtension that will be required to
implement #36096.
To address those issues, this commit introduces an overloaded variant
of resolveDependency() which accepts a custom parameter name.
Internally, a custom DependencyDescriptor has been implemented to
transparently support this use case.
See gh-36096
Closes gh-36534
Prior to this commit, BeanOverrideHandler contained a large amount of
logic solely related to search algorithms for finding handlers.
Consequently, BeanOverrideHandler took on more responsibility than it
ideally should. In addition, we will soon increase the complexity of
those search algorithms, and we will need to make another utility
method public for use outside the bean.override package.
To address those issues, this commit extracts the search utilities from
BeanOverrideHandler into a new BeanOverrideUtils class.
Closes gh-36533
Prior to this commit, `HttpMessageConverters` would consider the JAXB
message converters when building `HttpMessageConverters` instances.
We noticed that, on the server side, the Jakarta JAXB dependency is very
common on the classpath and often brought transitively. At runtime, this
converter can use significant CPU resources when checking the
`canRead`/`canWrite` methods. This can happen when content types aren't
strictly called out on controller endpoints.
This commit changes the auto-detection mechanism in
`HttpMessageConverters` to not consider the JAXB message converter for
server use cases.
For client use cases, we keep considering this converter as the runtime
cost there is lower.
Closes gh-36302
This commit links the Spring Framework Observability section in the
reference documentation to the Micrometer docs describing how
Observations are handled as metrics.
Closes gh-34994
Prior to this commit, the `DefaultRestClient` implementation would
look at the type of the returned value to decide whether the HTTP
response stream needs to be closed before returning.
As of gh-36380, this checks for `InputStream` and `InputStreamResource`
return types, effectively not considering `ResponseEntity<InputStream>`
and variants.
This commit ensures that `ResponseEntity` types are unwrapped before
checking for streaming types.
Fixes gh-36492
When the Accept-Language header is present but blank, defaultLocale
was ignored and fell back to Locale.getDefault() (JVM system locale).
A blank header represents the same intent as an absent header.
Closes gh-36513
Signed-off-by: elgun.shukurov <elgun.sukurov@kapitalbank.az>
Prior to this commit, the following warning was emitted in the build.
w: file:///<path>/spring-framework/framework-docs/src/main/kotlin/org/springframework/docs/core/aop/ataspectj/aopataspectjexample/ConcurrentOperationExecutor.kt:57:29 Unnecessary non-null assertion (!!) on a non-null receiver of type 'PessimisticLockingFailureException'.
Prior to this commit, the extension context scope used by the
SpringExtension defaulted to test-method scoped and could only be
changed on a per-class basis via the @SpringExtensionConfig
annotation. However, having to annotate each affected test class is
cumbersome for developers who wish to use test-class scoped extension
context semantics across their code base.
To address that, this commit introduces support for configuring the
global default extension context scope for the SpringExtension via
Spring properties or JUnit properties.
Specifically, this commit introduces a
`spring.test.extension.context.scope` property that can be set via the
SpringProperties mechanism or via a JUnit Platform configuration
parameter.
See gh-35697
Closes gh-36460
Prior to this commit, different resource resolvers would resolve
accepted codings from the HTTP request sent by the client. This would be
done with different implementations, which could lead to resolution
errors and desynchronizations.
This commit now introduced a new shared method in
`EncodedResourceResolver` (Servlet and Reactive) to perform a consisten
resolution.
Fixes gh-36507
- Avoid the use of assertThat(Arrays.equals(...))
- Convert assertThat(Boolean.FALSE).isEqualTo(x) to assertThat(x).isEqualTo(Boolean.FALSE)
- Convert assertThat(Boolean.TRUE).isEqualTo(x) to assertThat(x).isEqualTo(Boolean.TRUE)
- Convert assertThat(x.equals(y)).isTrue() to assertThat(x).isEqualTo(y)
- Convert assertThat(x.equals(y)).isFalse() to assertThat(x).isNotEqualTo(y)
- Remove unnecessary parentheses in assertThat() arguments
- Convert assertThat(x instanceof X).isFalse() to assertThat(x).isNotInstanceOf()
- Convert assertThat(x instanceof X).isTrue() to assertThat(x).isInstanceOf()
- Convert assertThat(!x).isTrue() to assertThat(x).isFalse()
- Inline conditions in assertThat() statements
Closes gh-36504
Although this commit also changes the visibility of some test methods
to package-private, the remainder of that task will be addressed in
conjunction with gh-36496.
Closes gh-36495
Updates the Content-Disposition header creation logic to use only
ISO-8859-1 characters for the fallback 'filename' parameter instead of
RFC 2047 encoded strings. Non-compatible characters are replaced with '_'.
This does not remove the ability to parse RFC 2047 encoded filenames.
Closes gh-36328
Signed-off-by: Tobias Fasching <tobias.fasching@outlook.com>
Prior to this commit, the `StandardWebSocketUpgradeStrategy` would get
the HTTP headers from the handshake request and store them in the
WebSocket session for the entire duration of the session.
As of gh-36334, Spring MVC manages HTTP directly with a native API
instead of copying them. This improves performance but also uncovered
this bug: we cannot keep a reference to HTTP headers once the HTTP
exchange is finished, because such resources can be recycled and reused.
This commit ensures that the handshake headers are copied into the
session info to keep them around for the entire duration of the session.
Without that, Tomcat will raise an `IllegalStateException` at runtime.
This was already done for WebFlux in SPR-17250, but the latest header
management changes in Framework uncovered this issue for the Standard
WebSocket container case.
Fixes gh-36486
Prior to this commit, Spring web frameworks were using the
"application/x-ndjson" media type for streaming JSON payloads delimited
with newlines.
The "application/jsonl" media type seems to gain popularity in the
broader ecosystem and could supersede NDJSON in the future. This commit
adds support for JSON Lines as an alternative.
Closes gh-36485
Introduces a general-purpose consumeContent method on Resource and EncodedResource with special behavior for multi-content resources. Regular getInputStream/getReader calls will expose the merged content of all same-named resources in the classpath.
Closes gh-36415
Prior to this commit, the `WebTestClient` could only accept non-nullable
types in its `expectBodyList<T>` Kotlin extension function.
This commit relaxes this requirements to allow for more assertions.
Fixes gh-36476
This commit ensures that `ParameterizedTypeReference<T>` can accept
nullable types. This is especially useful for Kotlin extension functions
and assertion contracts.
Fixes gh-36477
Since the Spring Framework uses American English spelling, this commit
updates Javadoc and the reference manual to ensure consistency in that
regard. However, there are two exceptions to this rule that arise due
to their use within a technical context.
- We use "cancelled/cancelling" instead of "canceled/canceling" in
numerous places (including error messages).
- We use "implementor" instead of "implementer".
Closes gh-36470
Prior to this commit, if a superclass or enclosing test class (such as
one annotated with @SpringBootTest or simply
@ExtendWith(SpringExtension.class)) was not annotated with
@ContextConfiguration (or @Import with @SpringBootTest), the
ApplicationContext loaded for a subclass or @Nested test class would
not use any default context configuration for the superclass or
enclosing test class.
Effectively, a default XML configuration file or static nested
@Configuration class for the superclass or enclosing test class was
not discovered by the AbstractTestContextBootstrapper when attempting
to build the MergedContextConfiguration (application context cache key).
To address that, this commit introduces a new
resolveDefaultContextConfigurationAttributes() method in
ContextLoaderUtils which is responsible for creating instances of
ContextConfigurationAttributes for all superclasses and enclosing
classes. This effectively enables AbstractTestContextBootstrapper to
delegate to the resolved SmartContextLoader to properly detect a
default XML configuration file or static nested @Configuration class
even if such classes are not annotated with @ContextConfiguration.
Closes gh-31456
This commit revises the resolveExplicitTestContextBootstrapper()
algorithm in BootstrapUtils to allow a local @BootstrapWith annotation
to override a meta-annotation within the same composed annotation.
Closes gh-35938
This commit apply extra checks to ScriptTemplateView resource handling
with ResourceHandlerUtils, consistently with what is done with static
resource handling.
Closes gh-36458
Restore both WebMVC and WebFlux variants that were deleted
by mistake in commit 4db2f8ea1b.
This commit also removes the empty resource loader path, as it is not
needed for the main WEB-INF/ use case that is typically configured
explicitly by the user, and not needed to pass the restored tests.
Closes gh-36456
Prior to this commit, the `ClassFile` based implementation of
`AnnotationMetadata` would rely on the `NestHost` class element to get
the enclosing class name for a nested class.
This approach works for bytecode emitted by Java11+, which aligns with
our Java17+ runtime policy. But there are cases where bytecode was not
emitted by a Java11+ compiler, such as Kotlin. In this case, the
`NestHost` class element is absent and we should instead use the
`InnerClasses` information to get it.
This commit makes use of `InnerClasses` to get the enclosing class name,
but still uses `NestHost` as a fallback for anonymous classes.
Fixes gh-36451
Uses ClassFileAnnotationMetadata name for actual AnnotationMetadata.
Moves JSR-305 dependency to compile-only for all spring-core tests.
Closes gh-36432
Prior to this commit, the `setMessageConverters` method would have
private visibility. But `initBodyConvertFunction`, which is `protected`,
relies on the message converters being set in the first place.
While this works with `RestTemplate` because this is done automatically,
the `RestClient` does offer a builder method to configure a
`ResponseErrorHandler` and this makes it impossible to configure
converters in this case.
This commit aligns the method visibility by making it protected.
Closes gh-36434
Prior to this commit, our implementation of Server Sent Events (SSE),
`SseEmitter` (MVC) and `ServerSentEvent` (WebFlux), would not guard
against invalid characters if the application mistakenly inserts such
characters in the `id` or `event` types.
Both implementations would also behave differently when it comes
to escaping comment multi-line events.
This commit ensures that both implementations handle multi-line comment
events and reject invalid characters in id/event types.
This commit also optimizes `String` concatenation and memory usage
when writing data.
Fixes gh-36440
This will:
1. Mathematical Distribution (Collision Reduction)
2. Pipelining and CPU Caching
3. Avoiding "Method Heavy" Expressions
See gh-36325
Signed-off-by: Agil <41694337+AgilAghamirzayev@users.noreply.github.com>
- Extract code examples to separate Java, Kotlin, and XML files
- Add Kotlin configuration sample alongside Java
- Change "Java Config" terminology to "Programmatic Configuration"
- Use include-code directive for better maintainability
See gh-36323
Signed-off-by: jisub-dev <kimjiseob1209@gmail.com>
The internal buildMergedContextConfiguration() method in
AbstractTestContextBootstrapper originally resolved the
ApplicationContextInitializer set only once. However, the changes made
in commit 2244461778 introduced a regression resulting in the
initializers being resolved twice: once for validation and once for
actually building the merged context configuration. In addition, the
resolution for validation does not honor the inheritInitializers flag
in ContextConfigurationAttributes.
To address these issues, buildMergedContextConfiguration() once again
resolves the context initializers once via
ApplicationContextInitializerUtils.resolveInitializerClasses().
See gh-18528
Closes gh-36430
The RequestHeaderOverrideWrapper did not deduplicate in keySet()
across underlying headers and overrides.
A similar change in size() even if it was working correctly,
to align with keySet and make it more efficient.
Closes gh-36418
This change ensures that maxFramePayloadLength from
WebsocketClientSpec is passed to ReactorNettyWebSocketSession.
Previously, the session used the default 64KB limit regardless
of client configuration, causing TooLongFrameException when
receiving larger frames from servers like Tomcat or Jetty.
See gh-36370
Signed-off-by: Artem Voronin <artem.voronin.dev@gmail.com>
Ideally, we should be able to reuse the ContextLoader that was resolved
in buildDefaultMergedContextConfiguration(); however, since we have
been informed that some implementations of resolveContextLoader()
mutate the state of the supplied ContextConfigurationAttributes to
detect default configuration classes, we need to invoke
resolveContextLoader() on the completeDefaultConfigAttributesList as
well in order not to break custom TestContextBootstrappers that exhibit
such side effects.
Closes gh-36390
Traditionally, AbstractResourceBasedMessageSource has only had a
setDefaultEncoding() method which accepts the name of the default
encoding character set. However, although we have recently made a
concerted effort within the framework to introduce support for
supplying a Charset instead of a character set's name, we had
overlooked this particular scenario.
In light of that, this commit introduces setDefaultCharset(Charset) and
getDefaultCharset() methods in AbstractResourceBasedMessageSource and
makes direct use of the available Charset in
ReloadableResourceBundleMessageSource and ResourceBundleMessageSource.
Furthermore, although technically a regression in behavior, invoking
setDefaultEncoding() on such MessageSource implementations with an
invalid character set name now results in an immediate
UnsupportedCharsetException at configuration time instead of a
NoSuchMessageException at runtime, which will help users to more easily
detect misconfiguration.
Closes gh-36413
This commit renames the
org.springframework.test.context.configuration.interfaces package to
org.springframework.test.context.config.interfaces in order to colocate
"config" related tests under the same package.
In Spring Framework 7.1, the TestContext Framework will reliably detect
all default context configuration within the type hierarchy or
enclosing class hierarchy (for @Nested test classes) above a given
test class; however, test suites may encounter failures once we make
that switch in behavior.
In order to help development teams prepare for the switch in 7.1, this
commit logs a warning similar to the following whenever default context
configuration is detected but currently ignored.
WARN - For test class [org.example.MyTests$NestedTests], the
following 'default' context configuration classes were detected but
are currently ignored: org.example.MyTests$Config. In Spring
Framework 7.1, these classes will no longer be ignored. Please update
your test configuration accordingly. For details, see:
https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/ctx-management/default-config.html
See gh-31456
See gh-36392
Closes gh-36390
The methods to build a request in RestClientAdapter and WebClientAdapter
are now public to make it easier to create a custom adapter that wraps
the built-in ones and delegates for methods that can be the same.
Closes gh-36374
Prior to this commit, flush calls on the output stream returned by
`ServletServerHttpResponse#getBody` would be delegated to the Servlet
response output stream.
This can cause performance issues when `HttpMessageConverter` and other
web components write and flush multiple times to the response body.
Here, the Servlet container is in a better position to flush to the
network at the optimal time and buffer the response body until then.
This is particularly true for `HttpMessageConverters` when they flush
many times the output stream, sometimes due to the underlying codec
library. Instead of revisiting the entire message converter contract, we
are here ignoring flush calls to that output stream.
This change does not affect the client side, nor the
`ServletServerHttpResponse#flush` calls.
This commit also introduces a new Spring property
`"spring.http.response.flush.enabled"` that reverts this behavior change
if necessary.
Closes gh-36385
This commit adapts RuntimeHints to be compatible with v1.2.0 of the
GraalVM metadata format. The changes are as follows:
* Resources and resource bundles are now defined at the same level. This
is transparent to users.
* Serialization is no longer a top-level concept, but rather an
attribute of a type or proxy. The top-level concept has been deprecated
and the relevant methods have been added.
Closes gh-36379
Prior to this commit, a few implementations of the `HttpMessageConverter`
contract were inheriting from abstract classes. Those classes were
performing extra `OutputStream#flush` on the response body even though
this is the responsibility of the super class. Such abstract classes
do flush already, after delegating to the `writeInternal` method.
This commit ensures that we remove such extra calls as they tend to
waste resources for no added benefit.
Closes gh-36383
This commit updates the target type detection in
`ResourceHttpMessageConverter` to only support target types that are
relevant: `InputStreamResource` for streaming, and types assignable from
`ByteArrayResource` for non-streaming cases.
Closes gh-36368
The `AbstractMessageConverterMethodProcessor` is in charge of handling
controller method return values and to write those as HTTP response
messages. The content negotiation process is an important part.
The `MimeTypeUtils#sortBySpecificity` is in charge of sorting inbound
"Accept" media types by their specificity and reject them if the list
is too large, in order to protect the application from ddos attacks.
Prior to this commit, the content negotiation process would first get
the sorted "Accept" media types, the producible media types as
advertized by message converters - and collect the intersection of both
in a new list (also sorted by specificity). If the "Accept" list is
large enough (but under the limit), the list of compatible media types
could exceed that limit because duplicates could be introduced in that
list: several converters can produce the same content type.
This commit ensures that compatible media types are collected in a set
to avoid duplicates. Without that, exceeding the limit at this point
will throw an `InvalidMimeTypeException` that's not handled by the
processor and result in a server error.
Fixes gh-36300
This commit fixes the `configureMessageConverters` and
`configureMessageConvertersList` behavior.
`configureMessageConverters` was not executing consumers in their order
of registration (but in the reverse order).
`configureMessageConvertersList` was not executing multiple consumers
and was instead executing the first consumer multiple times.
This commit fixes both issues.
Fixes gh-36332
get method skips containsKey and instead checks if the enumeration
has elements, which should give the same behavior other than for
headers without values.
See gh-36334
- Optimize get method for request headers
- Update keySet methods to use custom extension of AbstractSet
- Drop use of native Tomcat headers, which could be an issue for
request and response wrappers that override header methods.
The performance of Servlet adapters should be similar for the
commonly used methods, and it should be possible to optimize
further for the future in HttpHeaders (e.g. by adding a
set alternative to put), and requesting Servlet API refinements.
Closes gh-36334
Prior to this commit, the reactive `MultipartParser` and `PartGenerator`
types were leaking memory at runtime in specific cases:
* many HTTP clients must send multipart requests to be parsed and close
the connection while uploading
* the `PartGenerator` must be configured to write file parts to
temporary files on disk
* concurrency, upload speed must be important to trigger cases where the
file system is not fast enough to consume incoming buffers
The `MultipartParser` parses and emits `BodyToken` to its sink
(here, the `PartGenerator`). By definition, Reactor's `FluxSink` when
created with `Flux.create(FluxSink)` will use a "buffer" strategy and
will queue emitted elements if they cannot be consumed.
Here, the cancellation signal does dispose internal states in the
`MultiPartParser` and `PartGenerator` but does not clear the internal
queue in `FluxSink`.
This commit ensures that an operation is registered to release buffers
on the discard event.
Fixes gh-36262
Prior to this commit, the `MediaType` and `MimeType` "copy" constructors
would not leverage the fact that the existing instance has been
validated already (types, subtype and parameters have been checked
already for errors) and the entire validation would be performed again.
This would also allocate map instances in the process.
This commit ensures that the already validated information is reused
directly and that we avoid unnessecary operations and allocations for
such constructors.
Closes gh-36318
Prior to this commit, the findAutowiredAnnotation() method in
AutowiredAnnotationBeanPostProcessor fully supported finding
@Autowired as a meta-annotation; however, the isRequired() method in
QualifierAnnotationAutowireCandidateResolver only found @Autowired as
a "directly present" annotation without any support for
meta-annotations.
For consistency and to avoid bugs, this commit revises
QualifierAnnotationAutowireCandidateResolver so that we always support
@Autowired as a meta-annotation.
Closes gh-36315
This commit revises AutowiredAnnotationBeanPostProcessor so that
determineRequiredStatus(MergedAnnotation<?>) only looks up the required
attribute once.
Closes gh-36314
The builder for `HttpMessageConverters` allows for auto-detection of
message converters on the classpath and their default registration when
`registerDefaults()` is called. Once called, there is no way to undo
this.
This commit adds a new `disableDefaults()` method to disable the default
registration and take full control over the list of message converters.
Closes gh-36303
Prior to this commit, AnnotationConfigUtils looked up @Lazy as a
meta-annotation at arbitrary depths (e.g., when used as a
meta-meta-annotation); however,
ContextAnnotationAutowireCandidateResolver only found @Lazy as a
"directly present" meta-annotation.
For consistency, this commit revises
ContextAnnotationAutowireCandidateResolver so that it also finds @Lazy
as a meta-annotation at arbitrary depths.
Closes gh-36306
Prior to this commit, ValidationAnnotationUtils looked up @Validated
as a meta-annotation at arbitrary depths (e.g., when used as a
meta-meta-annotation) in determineValidationGroups() but only as a
"directly present" meta-annotation in determineValidationHints().
For consistency, this commit revises determineValidationHints() so that
it finds @Validated as a meta-annotation at arbitrary depths as well.
Closes gh-36274
Prior to this commit, the `HttpEntityMethodProcessor` would create a new
`ServletServerHttpRequest` input message to parse the native Servlet
request, but would not reuse it for reading the request body using the
message converters.
In gh-32471, we applied a change that updates HTTP headers accordingly
when request parameters are read. But not reusing the input message
means that we are losing this update when instantiating the resulting
`HttpEntity`.
This commit ensures that `HttpEntityMethodProcessor` uses the input
message it just created when decoding the request body.
Fixes gh-36298
Prior to this commit, an attempt to restart the
StompBrokerRelayMessageHandler (SBRMH) resulted in an
IllegalStateException stating that the ReactorNettyTcpClient was still
in the process of "Shutting down." The reason is that a
ReactorNettyTcpClient cannot be restarted after it has been closed, and
that is by design.
To address that issue, this commit introduces an
`internallyManagedTcpClient` flag in SBRMH that is used to track
whether SBRMH is in charge of managing the TcpClient internally or if
the TcpClient was supplied by the user and is therefore managed
externally.
If SBRMH manages the TcpClient internally, isPauseable() returns
`true`, and the `tcpClient` field is set to null (in stopInternal())
when the handler is stopped. Consequently, a new internally managed
TcpClient will be created when the handler is restarted.
If the TcpClient is managed externally, the handler is not considered
to be "pauseable", and a reference to the externally managed TcpClient
is retained after the handler has been stopped. If the
ApplicationContext is subsequently restarted, the externally managed
TcpClient will be reused -- which may or may not work, depending on the
implementation of the TcpClient. Note, however, that this has always
been the behavior of SBRMH with regard to stop/start scenarios for
externally managed TcpClients.
Closes gh-36266
Prior to this commit, the "application/*+json" wildcard MIME type was
added to the list of supported MIME types in the JSON messaging
converter. This change wasn't fully reflected in the
`AbstractMessageConverter`, because only strict matching of type and
subtybe were considered.
This commit updates the `AbstractMessageConverter` to not only check the
type and subtype, but also check whether the supported MIME type
includes the one given as a parameter.
Fixes gh-36285
Includes fix for consistent PersistenceException in case of no unit found for name.
Includes proper tests for Local(Container)EntityManagerFactoryBean with scan setup.
Closes gh-36270
Closes gh-36271
This commit also updates the Javadoc for the SpringExtension and
@SpringExtensionConfig to point out that the SpringExtension always
uses a test-class scoped ExtensionContext if
@TestInstance(Lifecycle.PER_CLASS) semantics are in effect.
Closes gh-36240
This PR optimizes the performance of NamedParameterUtils#buildValueArray by deferring the call to findParameter(declaredParams, paramName, i).
Changes: In the original implementation, findParameter was called for every parameter in the loop, regardless of whether the paramValue retrieved from paramSource was already an instance of SqlParameterValue.
Since findParameter involves iterating through the declaredParams list (or performing lookups), skipping this call when paramValue instanceof SqlParameterValue is true reduces unnecessary CPU cycles and memory access, especially for queries with a large number of parameters or long declaredParams lists.
Signed-off-by: qwding <761945125@qq.com>
Prior to this commit, the `Netty4HeadersAdapter` `MultiValueMapi#remove`
implementation would return an empty list if no value was present. This
is not consistent with other implementations.
This change ensures that `null` is returned for those cases.
Fixes gh-36226
Use helpers from java.nio.file.Files for some methods in FileCopyUtils.
Additionally, add unit tests for the various file-related methods.
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Prior to this commit, "new RetryTask<>" declarations whose
TaskCallbacks (implemented as lambda expressions) did not actually
throw an exception resulted in a compilation error in Eclipse:
"Unhandled exception type Exception".
This is due to the fact that RetryTask is declared with "E extends
Exception", and the Eclipse compiler therefore infers that the lambda
expression potentially throws a checked Exception.
To address that, this commit explicitly declares that the affected
lambda expressions throw unchecked RuntimeExceptions:
"new RetryTask<String, RuntimeException>"
Update `YamlProcessor` to allow any value to be inserted for
empty entries. This update will allow blank strings to be used
instead of `null` which better aligns with the way that
`.properties` files are loaded.
This update also allows allows the specified `emptyValue` to be
inserted instead of a blank String when the YAML contains `null`
or `~` values.
See gh-36197
See gh-19986
Signed-off-by: Phillip Webb <phil.webb@broadcom.com>
Add an additional `getFlattenedMap` method to `YamlProcessor` to allow
the resulting flattened map to include nulls.
This update will allow processor subclasses to tell the difference
between YAML that is defined with an empty object vs missing the key
entirely:
e.g.:
application:
name: test
optional: {}
vs
application:
name: test
optional: {}
Closes gh-36197
Signed-off-by: Phillip Webb <phil.webb@broadcom.com>
Prior to this commit, test methods in CaffeineReactiveCachingTests
were parameterized twice with the same configuration class.
See gh-31637
See gh-35833
In commit 9711db787e, we introduced support for disabling test
application context pausing via a Spring property or JVM system
property, as follows.
-Dspring.test.context.cache.pause=never
However, users may actually be interested in keeping the pausing
feature enabled if contexts are not paused unnecessarily.
To address that, this commit introduces a new
PauseMode.ON_CONTEXT_SWITCH enum constant which is now used by default
in the DefaultContextCache.
With this new pause mode, an unused application context will no longer
be paused immediately. Instead, an unused application context will be
paused lazily the first time a different context is retrieved from or
stored in the ContextCache. This effectively means that an unused
context will not be paused at all if the next test class uses the same
context.
Although ON_CONTEXT_SWITCH is the now the default pause mode, users
still have the option to enable context pausing for all usage scenarios
(not only context switches) by setting the Spring property or JVM
system property to ALWAYS (case insensitive) — for example:
-Dspring.test.context.cache.pause=always
This commit also introduces a dedicated "Context Pausing" section in
the reference manual.
See gh-36117
Closes gh-36044
Replace legacy Groovy DSL property assignment (space-separated) with
the standard assignment operator (=) in spring-aspects.gradle.
The legacy syntax is deprecated in Gradle 9 and will be removed in
Gradle 10. This change eliminates deprecation warnings during the
build and ensures future compatibility.
See gh-36132
Signed-off-by: Yejeong, Ham <dev@thelightway.kr>
This commit simplifies TransactionalOperator.executeAndAwait by removing
Optional. It is based on a proposal by @vlsi refined to handle properly
reactive transaction commits (see related commit
217b6e37a6).
Closes gh-36039
Implement EmbeddedValueResolverAware to resolve ${...} placeholders
in @HttpExchange URL attributes.
See gh-36126
Signed-off-by: Juhwan Lee <jhan0121@gmail.com>
Spring Framework 7.0 introduced support for pausing inactive
application contexts between test classes and restarting them once they
are needed again. If pausing and restarting are fast, this feature does
not have a negative impact on test suites.
However, if the pausing or restarting of certain Lifecycle components
in the application context is slow, that can have a negative impact on
the duration of the overall test suite.
In gh-36044, we hope to find a way to avoid unnecessarily pausing an
application context after a test class if the same context is used by
the next test class that is run. That should help reduce the risk of a
negative impact caused by the pause/restart feature; however, for
certain scenarios that may not be enough. In light of that, this commit
introduces a mechanism for completely disabling the pausing feature via
a Spring property or JVM system property, as follows.
-Dspring.test.context.cache.pause=never
See gh-35168
See gh-36044
Closes gh-36117
Ensure that the DefaultApiVersionInserter does not re-encode existing parts
of the input URI by using the 'encoded' flag in UriComponentsBuilder.
This prevents percent-encoded characters (like %20) from being incorrectly
double-encoded to %2520 during the version insertion process.
See gh-36097
Signed-off-by: Nabil Fawwaz Elqayyim <master@nabilfawwaz.com>
Prior to this commit, the following method in AbstractMessageSendingTemplate
simply ignored the supplied headers map.
convertAndSend(Object, Map<String, Object>, MessagePostProcessor)
Closes gh-36120
Prior to this commit, if the JmsClient was configured with a default
destination name (instead of a default Destination), invoking the
sendAndReceive() variant which accepts a map of headers resulted in an
exception stating that a default destination is required.
To address that, this commit overrides the
convertSendAndReceive(Object, Map<String, Object>, Class<T>, MessagePostProcessor)
method in JmsMessagingTemplate to add support for both a default
Destination and a default destination name.
Closes gh-36118
Instead of making it async and having a sync subinterface variant,
this restores ApiVersionResolver to be as it was with an async
subinterface variant.
ApiVersionStrategy, and the infrastructure invoking it, remains
async first, but also accommodates sync resolvers.
This should provide a better balance with backwards compatibility
while also accommodating async version resolution as the less
common scenario.
See gh-36084
Prior to this commit, the algorithm behind determineBasicProperties()
in PropertyDescriptorUtils did not reliably resolve the correct write
method when one candidate write method had a parameter type that was a
subtype of another candidate write method whose parameter type was an
exact match for the resolved read method's return type.
In other words, the algorithm always resolved the candidate write
method with the most specific parameter type (similar to covariant
return types) which is not necessarily the resolved read method's
return type.
To address that, this commit ensures that determineBasicProperties()
always selects an exact match for the write method whenever possible.
As an added bonus, determineBasicProperties() no longer invokes
BasicPropertyDescriptor.getWriteMethod(), which avoids triggering the
resolution algorithm multiple times (when multiple write method
candidates exist), resulting in lazy resolution of the write method the
first time client code invokes getWriteMethod().
Closes gh-36113
This commit introduces ContextClassRequestBodyAdvice which adds a
"contextClass" hint allowing to resolve generics for Optional,
HttpEntity or ServerSentEvent container types.
Closes gh-36111
This commit introduces tests for proper support for non-generic types
in PropertyDescriptorUtils.determineBasicProperties(), effectively to
test the status quo and serve as regression tests.
While an API version may be important for mapping in an ERROR dispatch,
it is more important to allow the original exception to be handled.
Closes gh-36058
Among HandlerMapping's some may not expect an API version. This is why
those that do must be careful not to raise API validation errors if
they don't match the request.
Closes gh-36059
Use lazy evaluation in SingleCharWildcardedPathElement to avoid
unnecessary Character.toLowerCase() calls.
Resolves performance TODO from 2017.
Closes gh-36095
Signed-off-by: Minkyu Park <rb6609@naver.com>
This commit adds a new `configureMessageConvertersList` method on the
builder to add/remove/move converters in the resulting list before they
are individually post-processed.
This allows to re-introduce a behavior that was missing with the new
contract: the ability to append a converter at the end of the list.
See gh-36083
Signed-off-by: hayden.rear <hayden.rear@gmail.com>
This commit updates the HttpComponents HttpClient to refer to the parsed
`HttpEntity` for the content-related HTTP response headers such as
encoding and body length.
Closes gh-36100
The Java sample for "Locale Interceptor" shows a
`urlHandlerMapping.setUrlMap(Map.of("...` line due the inability to
disable the code chomping Asciidoctor extension with the code include
one. It will be fixed by a subsequent commit or a bug fix in
https://github.com/spring-io/asciidoctor-extensions.
Closes gh-36099
As a follow up to commit 4b07edbaeb, this commit introduces tests for
PropertyDescriptorUtils.determineBasicProperties() using types with
bounded generics.
Note, however, that the following test effectively fails, since
PropertyDescriptorUtils.determineBasicProperties() does not match the
behavior of java.beans.Introspector. Consequently, this test method
currently changes the expected write method type conditionally.
resolvePropertiesWithUnresolvedGenericsInSubclassWithOverloadedSetter()
See gh-36019
Like what we did for `@EnableWebMvc`, we want to remove `@EnableWebFlux`
from typical code snippets extending WebFluxConfigurer to make them more
Spring Boot friendly.
Closes gh-36091
This commits udpates ConverterFactory#getConverter to accept both
nullable and non-null T in the Converter return value.
Flexible nullability at ConverterFactory type level would have been
ideal, but is not possible due to how Kotlin deals with Class<T> when
T is nullable.
See gh-36063
This commit also replaces Arch Unit packageInfoShouldBeNullMarked() rule
by either configuring requireExplicitNullMarking = false when the whole
module does not have JSpecify annotations, or explicit @NullUnmarked
when some have and some don't.
See gh-36054
Prior to this commit, the determineBasicProperties() method in
PropertyDescriptorUtils did not reliably resolve read/write methods in
type hierarchies with generics. This utility method is used by
SimpleBeanInfoFactory which is used by BeanUtils and BeanWrapperImpl.
Thus, failure to reliably resolve read/write JavaBeans methods resulted
in bugs in certain scenarios.
For example, BeanUtils.copyProperties() randomly failed to copy certain
properties if the write method for the property could not be resolved.
To address such issues, this commit revises the implementation of
PropertyDescriptorUtils as follows.
1) Read methods with covariant return types are now consistently
resolved correctly.
2) If multiple ambiguous write methods are discovered, the algorithm now
checks for an exact match against the resolved generic parameter type
as a fallback.
Closes gh-36019
This commit updates the `HttpHeaders` javadoc to better reflect that
`asSingleValueMap()`, `asMultiValueMap()`, and `toSingleValueMap()` all
return case-sentitive map implementations.
Closes gh-36070
In gh-35947, the `Converter` contract was refined to allow for nullable
return values. This created a mismatch with the `ConverterFactory`
contract.
This commit fixes this mismatch by allowing nullable return values in
`Converter` instances created by `ConverterFactory`.
Fixes gh-36063
Prior to this commit, the `StringHttpMessageConverter` would perform a
flush after writing the body, via `StreamUtils#copy`. This operation is
not needed as a flush is already performed by the abstract class.
Flush calls by HTTP message converters is being reconsidered altogether
in gh-35427, but we should first remove this extra operation.
Closes gh-36065
Prior to this commit, we found in gh-35953 that using the `WebTestClient`
the following way leaks data buffers:
```
var body = client.get().uri("download")
.exchange()
.expectStatus().isOk()
.returnResult()
.getResponseBodyContent();
```
Here, the test performs expectations on the response status and headers,
but not on the response body. The WiretapConnector already supports this
case by subscribing to the Flux response body in those cases and
accumulating the entire content as a single byte[].
Here, the `DataBuffer` instances are not decoded by any `Decoder` and
are not released. This results in a memory leak.
This commit ensures that the automatic subscription in
`WiretapConnector` also releases the buffers automatically as the DSL
does not allow at that point to go back to performing body expectations.
Fixes gh-36050
This commit improves TestCompiler to expose both errors and warnings
instead of an opaque message. When compilation fails, both errors and
warnings are displayed.
This is particularly useful when combined with the `-Werror` option
that turns the presence of a warning into an error.
Closes gh-36037
This includes MethodParameter resolving getParameterName() by default now.
initParameterNameDiscovery(null) can be used to suppress such resolution.
Closes gh-36024
Prior to this commit, the `RfcUriParser` would ignore URI fragments if
their length is < 2. This commit fixes the length check to allow for
single char fragments when parsing URIs.
Fixes gh-36029
Prior to this commit, the `JdkClientHttpRequest` would add all values
from `HttpHeaders` to the native request builder. This could cause
`NullPointerException` being thrown at runtime because the `HttpClient`
does not support that.
This commit replicates a fix that was applied to the
`SimpleClientHttpRequest`, turning null values into empty "".
Fixes gh-35996
Return the requested resource as ErrorResponse.getDetailMessageArguments,
making it usable with message customization and i18n.
See gh-35758
Signed-off-by: Samuel Gulliksson <samuel.gulliksson@gmail.com>
Prior to this commit, if an enclosing test class (such as one annotated
with @SpringBootTest or simply @ExtendWith(SpringExtension.class))
was not annotated with @ContextConfiguration (or @Import with
@SpringBootTest), the ApplicationContext loaded for a @Nested test
class would not use any default context configuration for the enclosing
test class.
Effectively, a default XML configuration file or static nested
@Configuration class for the enclosing test class was not discovered
by the AbstractTestContextBootstrapper when attempting to build the
MergedContextConfiguration (application context cache key).
To address that, this commit introduces a new
resolveDefaultContextConfigurationAttributes() method in
ContextLoaderUtils which is responsible for creating instances of
ContextConfigurationAttributes for all superclasses and enclosing
classes. This effectively enables AbstractTestContextBootstrapper to
delegate to the resolved SmartContextLoader to properly detect a
default XML configuration file or static nested @Configuration class
even if such classes are not annotated with @ContextConfiguration.
Closes gh-31456
The error message in such cases now indicates that the retry process
is being aborted preemptively due to pending sleep time.
For example:
Retry policy for operation 'myMethod' would exceed timeout (5 ms) due
to pending sleep time (10 ms); preemptively aborting execution
See gh-35963
To improve diagnostics, this commit logs a DEBUG message including the
RetryException thrown by RetryTemplate when it's used behind the scenes
for @Retryable method invocations.
Closes gh-35983
Specifically, this commit introduces:
- timeout and timeoutString attributes in @Retryable
- a default getTimeout() method in RetryPolicy
- a timeout() method in RetryPolicy.Builder
- an onRetryPolicyTimeout() callback in RetryListener
- support for checking exceeded timeouts in RetryTemplate (also used
for imperative method invocations with @Retryable)
- support for checking exceeded timeouts in reactive pipelines with
@Retryable
Closes gh-35963
Prior to this commit, the `JdkClientHttpRequestFactory` would support
decompressing gziped/deflate encoded response bodies but would fail if
the response has no body but has a "Content-Encoding" response header.
This happens as a response to HEAD requests.
This commit ensures that only responses with actual message bodies are
decompressed.
Fixes gh-35966
This commit revises the type-level nullability declaration in
ConvertingComparator in order to adapt to recent nullability changes in
Converter.
This commit also revises the workaround in commit 53d9ba879d.
See gh-35947
As of Micrometer Tracing 1.6.0, the `Propagator.Getter` interface
adds a new `getAll` method with a default implementation return a
singleton collection.
This commit adds the missing implementation override in both Servlet and
Reactor web server contexts.
Fixes gh-35965
Add warnings to the class-level Javadoc for MergedAnnotations,
AnnotatedTypeMetadata, AnnotationMetadata, and MethodMetadata to point
out that annotations may be ignored if their attributes reference types
that are not present in the classpath.
Closes gh-35959
Allow defining converters that return non-null values by
leveraging flexible generic type level nullability in
org.springframework.core.convert.converter.Converter.
Closes gh-35947
In contrast to the previous commit, a warning similar to the following
is now logged in such cases.
WARN o.s.c.a.MergedAnnotation -
Failed to introspect meta-annotation @MyAnnotation on class
example.Config: java.lang.TypeNotPresentException:
Type example.OptionalDependency not present
See gh-35927
Prior to this commit, if a meta-annotation could not be loaded because
its attributes referenced types not present in the classpath, the
meta-annotation was silently ignored.
To improve diagnostics for such use cases, this commit introduces WARN
support in IntrospectionFailureLogger and revises AttributeMethods.canLoad()
to log a warning if a meta-annotation is ignored due to an exception
thrown while attempting to load its attributes.
For example, a warning similar to the following is now logged in such
cases.
WARN o.s.c.a.MergedAnnotation -
Failed to introspect meta-annotation @example.MyAnnotation on class
example.Config: java.lang.TypeNotPresentException:
Type example.OptionalDependency not present
This commit also improves log messages in AnnotationTypeMappings.
Closes gh-35927
With this commit, we now include snapshots for main (which currently
correlates to 7.0.x), 6.2.x, and 7.0.x to 9.*.x.
Closes gh-35923
(cherry picked from commit 305a512a55)
AbstractKotlinSerializationHttpMessageConverter#writeInternal is able to
resolve the ResolvableType from the Object parameter when the provided
one via the ResolvableType parameter is not resolvable, but
AbstractKotlinSerializationHttpMessageConverter#canWrite lacks of
such capability.
This commit refines
AbstractKotlinSerializationHttpMessageConverter#canWrite to resolve the
ResolvableType from the Class<?> parameter when the provided one via the
ResolvableType parameter is not resolvable.
Closes gh-35920
Since its inception, instantiating an `HttpEntity` makes its
`HttpHeaders` read-only. While immutability is an interesting design
principle, here we shouldn't enforce this.
For example, developers can expect to instantiate a `ResponseEntity`
and still mutate its headers.
Closes gh-35888
Includes alignment for direct Optional injection points, consistently registering an autowiredBeanNames entry for an Optional as well as a non-Optional injection result.
Closes gh-35373
Closes gh-35919
Prior to this commit, `RestTestClient` tests could only perform
expectations on the response without consuming the body. In this case,
the client could leak HTTP connections with the underlying HTTP library
because the response was not entirely read.
This commit ensures that the response is always fully drained before
performing expectations. The client is configured to buffer the response
content, so further body expectations are always possible.
Fixes gh-35784
Extending AbstractSmartHttpMessageConverter typically requires to
override both Class and ResolvableType variants of canRead. This was not
intended as SmartHttpMessageConverter interface has default methods
doing the conversion from Class parameters to ResolvableType ones, but
AbstractHttpMessageConverter overrides it.
This commit changes AbstractSmartHttpMessageConverter canRead/canWrite
overrides from ResolvableType to Class ones that delegate to the
ResolvableType variants. It also refines
AbstractJacksonHttpMessageConverter accordingly.
Closes gh-35916
The UserTransaction read-only semantics are still in discussion. If they turn out to be stricter than Spring's read-only hint, we should only apply them when configured with an explicit enforceReadOnly=true flag at the Spring JtaTransactionManager level (similar to the same-named flag in DataSourceTransactionManager).
See gh-35915
See gh-35633
The RuntimeBeanReference(name, type) constructor was introduced in 7.0;
however, BeanDefinitionPropertyValueCodeGeneratorDelegates in our AOT
infrastructure was not updated to support the new constructor.
This commit revises BeanDefinitionPropertyValueCodeGeneratorDelegates
to ensure that AOT generated code for a RuntimeBeanReference uses the
RuntimeBeanReference(name, type) constructor, thereby retaining the
originally configured bean name.
See gh-35101
Closes gh-35913
For defensiveness against a singletonInstance/initialized visibility mismatch, we accept the locking overhead for pre-initialized null values (where we need the initialized field) in favor of a defensive fast path for non-null values (where we only need the singletonInstance field).
Closes gh-35905
This commit refines BindingReflectionHintsRegistrar with additional
dynamic hints for application-defined types, main core Java conversion
ones being already covered by ObjectToObjectConverterRuntimeHints.
Closes gh-35847
This commit revises the Integration Testing chapter to reference the
"Spring Framework Artifacts" wiki page instead of the nonexistent
"Dependency Management" section of the reference manual.
Closes gh-35890
Otherwise some header values are changed from "GMT" to "Z" and
some tests are broken. We don't want to change the current
runtime behavior, so this commit reverts the related change to
keep using ZoneId.of("GMT") in HttpHeaders.
Closes gh-35861
An annotation-specified proxyTargetClass attribute must only be applied when true, otherwise we need to participate in global defaulting.
Closes gh-35863
ServerSentEvent and String checks, removed from
KotlinSerializationSupport in Spring Framework 7.0, are reintroduced by
this commit at the right level (KotlinSerializationSupport for
ServerSentEvent and KotlinSerializationString(Decoder|Encoder) for
String).
Closes gh-35885
This commit fixes ServerSentEvent handling with Jackson encoder
when no Accept header is specified.
It also moves the String checks to the JSON codec level, as they do not
make sense for binary formats.
Closes gh-35872
This commit aligns RestOperationsExtensions.kt nullability with the
Java APIs one, like what has been done in gh-35846 for JdbcOperations.
Closes gh-35852
This commit updates JdbcOperationsExtensions.kt to:
- Properly use the spread operator for invoking Java methods with
a varargs parameter
- Align JdbcOperationsExtensions return values nullability
with the Java API (breaking change)
- Use varargs where Java counterpart does (breaking change, undo some
changes from gh-34668)
- Use nullable args instead of non-nullable ones
Closes gh-35846
If the RestClient was built with default message converters, then
in mutate, the saved builder also has 0 converters, and adding a
interferes with default registrations.
We need to check if there are no converters at all, and if so
use the default registrations.
See gh-35793
Read the respective fields only once in the values(), entrySet(), and
keySet() methods.
Closes gh-35822
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
The Spliterators returned by values, entrySet, and keySet incorrectly
reported the SIZED characteristic, instead of CONCURRENT. This could
lead to bugs when the map is concurrently modified during a stream
operation.
For keySet and values, the incorrect characteristics are inherited from
AbstractMap, so to rectify that the respective methods are overridden,
and custom collections are provided that report the correct Spliterator
characteristics.
Closes gh-35817
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Since getApplicationContext() was originally not intended to be part of
the public API, its Javadoc is intentionally sparse. However, since it
is actually a public API used by third parties, this commit improves the
documentation for getApplicationContext() by pointing out that invoking
the method actually results in the context being eagerly loaded, which
may not be desired.
This commit also updates the Javadoc for supportsParameter() along the
same lines.
Closes gh-35764
This commit adds an integration test for `WebClient`, specifically
testing that a failure happening while pulishing the request body is
reported on the main reactive pipeline.
See gh-35678
Prior to this commit, `WebClientResponseException` would only support
the deprecated "unprocessable entity" status.
This commit adds the missing support for "unprocessable content" when
creating exceptions with `WebClientResponseException#create`.
Fixes gh-35802
Prior to this commit (and despite the changes made in commit
4593f877dd), WebSocketHttpHeaders was not compatible with the
HttpHeaders(HttpHeaders) constructor or the copyOf(HttpHeaders) and
readOnlyHttpHeaders(HttpHeaders) factory methods.
To address that, this commit revises the implementation of
WebSocketHttpHeaders so that it only extends HttpHeaders, analogous to
ReadOnlyHttpHeaders. In other words, WebSocketHttpHeaders no longer
stores or delegates to a local HttpHeaders instance.
Closes gh-35792
Prior to this commit, `HttpMessageConverters` would assert that the
given converter in `withXmlConverter` has a media type that is equal to
"application/xml" in its list of supported converters.
This approach would not work if the given converter supports
"application/xml;charset=UTF-8" because of the strict equal check being
performed.
This commit ensures that we only consider the type and subtype of the
considered media types when comparing, removing the parameters from the
picture.
Fixes gh-35801
Since HttpHeaders no longer implements MultiValueMap (see gh-33913),
a few interoperability issues have arisen between HttpHeaders and
WebSocketHttpHeaders.
To address those issues, this commit:
- Revises addAll(HttpHeaders), putAll(HttpHeaders), and putAll(Map) in
HttpHeaders so that they no longer operate on the HttpHeaders.headers
field.
- Overrides addAll(String, List), asSingleValueMap(), and
asMultiValueMap() in WebSocketHttpHeaders.
- Deletes putAll(HttpHeaders), putAll(Map), and forEach(BiConsumer) in
WebSocketHttpHeaders, since they do not need to be overridden.
This commit also removes unnecessarily overridden Javadoc in
WebSocketHttpHeaders and revises the implementation of several methods
in HttpHeaders so that they delegate to key methods such as get()
instead of directly accessing the HttpHeaders.headers field.
See gh-33913
Closes gh-35792
Consistently allow subtypes of ServerResponse to be returned for any
provided HandlerFunction and HandlerFilterFunction. Both allow use of
subtypes such as EntityServerResponse and RenderingResponse, and
in the end we support any ServerResponse.
Closes gh-35791
This commit picks up where commit a0baeae9cf left off.
Specifically, in order to align with the behavior of
AbstractMockHttpServletRequestBuilder, HtmlUnitRequestBuilder no longer
sets the local port in the MockHttpServletRequest.
See gh-35709
Prior to this commit, the `ReactorClientHttpRequestFactory` and the
`ReactorClientHttpRequest` would use the `Executor` from the current
event loop for performing write operations.
Depending on I/O demand, this work could be blocked and would result in
blocked Netty event loop executors and the HTTP client hanging.
This commit ensures that the client uses a separate Executor for such
operations. If the application does not provide one on the request
factory, a `Schedulers#boundedElastic` instance will be used.
Fixes gh-34707
Prior to this commit, Spring Framework's JSP form tags supported the
response encoding in most places; however, <form:select> and
<form:options> still did not support the response character encoding.
To address that, this commit updates SelectTag, OptionsTag, and
OptionWriter to provide support for response character encoding in the
`select` and `options` JSP form tags.
See gh-33023
Closes gh-35783
This commit adds a new withKotlinSerializationCborConverter
method to HttpMessageConverters and updates DefaultHttpMessageConverters
to put JSON and CBOR Kotlin Serialization converters before
their Jackson/GSON/JSONB counterparts with their new default
behavior that only handles classes with `@Serializable` at
type or generics level.
When there is no alternative converter for the same mime type,
Kotlin Serialization converters handle all supported cases.
Closes gh-35761
This commit updates Kotlin serialization converters to perform
an additional check invoking
KotlinDetector#hasSerializableAnnotation to decide if the
related type should be processed or not.
The goal is to prevent in the default arrangement conflicts
between general purpose converters like Jackson and
Kotlin serialization when both are used.
New constructors allowing to specify a custom predicate
are also introduced.
See gh-35761
This commit updates BaseDefaultCodecs by adding Kotlin
Serialization codecs before their Jackson/GSON counterparts
with their new default behavior that only handles classes with
`@Serializable` at type or generics level.
When there is no alternative codec for the same mime type,
Kotlin Serialization codecs handle all supported cases.
This commit also adds missing Jackson CBOR codecs, and moves both
CBOR and Protobuf codecs to a lower priority, as they are less
commonly used than JSON ones, with the same ordering used on
Spring MVC side.
See gh-35761
Closes gh-35787
This commit updates Kotlin serialization codecs to perform
an additional check invoking
KotlinDetector#hasSerializableAnnotation to decide if the
related type should be processed or not.
The goal is to prevent in the default arrangement conflicts
between general purpose codecs like Jackson and
Kotlin serialization when both are used.
New constructors allowing to specify a custom predicate
are also introduced.
See gh-35761
This commit introduces a KotlinDetector#hasSerializableAnnotation
utility method designed to detect types annotated with
`@Serializable` at type or generics level.
See gh-35761
Prior to this commit, the maximum number of retry attempts was
configured via @Retryable(maxAttempts = ...),
RetryPolicy.withMaxAttempts(), and RetryPolicy.Builder.maxAttempts().
However, this led to confusion for developers who were unsure if
"max attempts" referred to the "total attempts" (i.e., initial attempt
plus retry attempts) or only the "retry attempts".
To improve the programming model, this commit renames maxAttempts to
maxRetries in @Retryable and RetryPolicy.Builder and renames
RetryPolicy.withMaxAttempts() to RetryPolicy.withMaxRetries(). In
addition, this commit updates the documentation to consistently point
out that total attempts = 1 initial attempt + maxRetries attempts.
Closes gh-35772
This commit ensures that the JAR verification task runs on JDK 25 as
this feature has been introduced in https://bugs.openjdk.org/browse/JDK-8355940
Fixes gh-35777
See gh-35773
This commit ensures that both `VirtualThreadDelegate` implementations
expose the same public API. If not, JAR verification fails with the
following message:
```
jar --validate --file spring-core-6.2.13-SNAPSHOT.jar
entry: META-INF/versions/21/org/springframework/core/task/VirtualThreadDelegate.class, contains a class with different api from earlier version
```
Fixes gh-35773
Prior to this commit, HtmlUnitRequestBuilder set the server port in the
MockHttpServletRequest to -1 if the URL did not contain an explicit
port. However, that can lead to errors in consumers of the request that
do not expect an invalid port number.
In addition, HtmlUnitRequestBuilder always set the remote port in the
MockHttpServletRequest to the value of the server port, which does not
make sense, since the remote port of the client has nothing to do with
the port on the server.
To address those issues, this commit revises HtmlUnitRequestBuilder so
that it:
- Does not set the server and local ports if the explicit or derived
default value is -1.
- Consistently sets the server and local ports to the same valid value.
- Does not set the remote port.
Closes gh-35709
Prior to this commit, gh-35213 allowed wildcard path elments at the
start of path patterns. This came with an additional constraint that
rejected such patterns if the pattern segment following the wildcard one
was not a literal:
* `/**/{name}` was rejected
* `/**/something/{name}` was accepted
The motivation here was to make the performance impact of wildard
patterns as small as possible at runtime.
This commit relaxes this constraint because `/**/*.js` patterns are very
popular in the security space for request matchers.
Closes gh-35686
This commit improves the reference document to better reflect the
different between `*` or `{name}` on one side, and `**` or `{*path}` on
the other.
The former patterns only consider a single path segment and its content,
while the latter variants consider zero or more path segments. This
explains why `/test/{*path}` can match `/test`.
Closes gh-35727
Although @PersistenceContext and @PersistenceUnit are still not
supported in tests running in AOT mode, as of Spring Framework 7.0,
developers can inject an EntityManager or EntityManagerFactory into
tests using @Autowired instead of @PersistenceContext and
@PersistenceUnit, respectively.
See commit 096303c477
See gh-33414
Closes gh-31442
The JsonConverterDelegate interface replaces usages of
HttpMessageContentConverter to provides the flexibility to use either
message converters or WebFlux codecs.
HttpMessageContentConverter is deprecated, and replaced with a package
private copy (DefaultJsonConverterDelegate) in the
org.springframework.test.json package that is accessible through
a static method on JsonConverterDelegate.
See gh-35737
Prior to this commit, the `MappingMediaTypeFileExtensionResolver` would
resolve file extensions for a given media type by using a direct lookup
using the given media type provided by the request.
If the request contains a quality parameter like
"application/json;q=0.9", this would not resolve configured file
extensions for this media type.
While other media type parameters can be meaningful, the quality
parameter should not be used for lookups. This commit ensures that the
quality parameter is dropped before performing lookups.
Fixes gh-35754
Prior to this commit, an attempt to use @MockitoSpyBean to spy on a
scoped proxy configured with
@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS) resulted in an
exception thrown by Mockito when the spy was stubbed. The exception
message stated "Failed to unwrap proxied object" but did not provide
any further insight or context for the user.
The reason is that ScopedProxyFactoryBean is used to create such a
scoped proxy, which uses a SimpleBeanTargetSource, which is not a
static TargetSource. Consequently,
SpringMockResolver.getUltimateTargetObject(Object) is not able to
unwrap the proxy.
In order to improve diagnostics for users, this commit eagerly detects
an attempt to spy on a scoped proxy and throws an exception with a
meaningful message. The following is an example, trimmed stack trace
from the test suite.
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'myScopedProxy': Post-processing of
FactoryBean's singleton object failed
...
Caused by: java.lang.IllegalStateException:
@MockitoSpyBean cannot be applied to bean 'myScopedProxy', because
it is a Spring AOP proxy with a non-static TargetSource. Perhaps you
have attempted to spy on a scoped proxy, which is not supported.
at ...MockitoSpyBeanOverrideHandler.createSpy(MockitoSpyBeanOverrideHandler.java:78)
Closes gh-35722
Prior to this commit, the `HttpComponentsClientHttpRequestFactory` would
set the connection timeout on the request configuration. This has been
deprecated by the client itself and this value should be set while
creating the client on the connection manager itself.
This commit deprecates this method, as there is no way for the factory
to set this value anymore.
Closes gh-35748
Prior to this commit, `HttpMessageConverters` would consider the Kotlin
Serialization JSON converter as an alternative to the Jackson variant.
As seen in related issues, this converter is more commonly used for
annotated classes specifically and applications often rely on Jackson
acting as a fallback for types not supported by Kotlin Serialization.
This commit enables applications to configure such a converter on
`HttpMessageConverters` and order it ahead of of the JSON one.
Closes gh-35733
This commit adds AOT support for discovering @Nested test classes
within a @ClassTemplate test class, which includes
@ParameterizedClass test classes.
Closes gh-35744
Switching from @PersistenceContext to @Autowired for dependency
injection in tests allows such tests to participate in AOT processing.
Note, however, that we still have TestNG-based tests that use
@PersistenceContext — for example, AbstractEjbTxDaoTestNGTests.
See gh-29122
See gh-31442
See gh-33414
Replace obsolete Concourse pipeline reference with GitHub Actions.
The Concourse link returns 404.
See gh-35746
Signed-off-by: Moad ELFATIHI <elfatihi.moad@gmail.com>
The MockMvcClientHttpRequestFactoryTests variant for RestTestClient was
copied from MockMvcClientHttpRequestFactoryTests which actually uses
MockMvcClientHttpRequestFactory. In addition,
MockMvcClientHttpRequestFactoryTests unnecessarily used the
SpringExtension.
This commit therefore renames the class to MockMvcRestTestClientTests
and removes the use of the SpringExtension.
See gh-29122
This commit upgrades our test suite to use JUnit 6.0.1 and removes the
systemProperty("junit.platform.discovery.issue.severity.critical", "WARNING")
configuration from spring-test.gradle, so that all discovery issues will
fail the build for the spring-test module as well.
In addition, this commit prevents potential AOT test scanning failures
for JUnit 4 tests by setting the
"junit.vintage.discovery.issue.reporting.enabled" configuration
parameter to "false" in TestClassScanner.
See https://github.com/junit-team/junit-framework/issues/5030
Closes gh-35740
When JAR manifest Class-Path entries contain absolute paths (as Gradle
creates on Windows for long classpaths), PathMatchingResourcePatternResolver
incorrectly rejected them.
Fixes#35730
Signed-off-by: Artur Signell <artur@vaadin.com>
Prior to this commit, the `HttpMessageConverters` builder API had
methods like "jsonMessageConverter" for configuring a specific converter
for JSON support. This converter would be always configured at a given
position, even if default converters registration is not requested.
On the other hand, `customMessageConverter` would add any converter
ahead of the list, in all cases. This difference was not conveyed as it
should by the API.
This commit makes the following changes:
* builder methods are renamed to `withJsonConverter` and variants, to
better convey the fact that those are replacing the default converter
for a given format.
* `customMessageConverter` is renamed to `addCustomConverter` to better
reflect the additive aspect.
* the JavaDoc has been updated accordingly
* `withJsonConverter` and others are now only effective if the default
registration of auto-detected converters is requested. This better
aligns with the behavior in the reactive codecs configuration
Closes gh-35704
When concurrency limiting is enabled via setConcurrencyLimit() and
thread creation fails in doExecute() (e.g., OutOfMemoryError from
Thread.start()), the concurrency permit acquired by beforeAccess()
is never released because TaskTrackingRunnable.run() never executes.
This causes the concurrency count to permanently remain at the limit,
causing all subsequent task submissions to block forever in
ConcurrencyThrottleSupport.onLimitReached().
Root cause:
- beforeAccess() increments concurrencyCount
- doExecute() throws Error before thread starts
- TaskTrackingRunnable.run() never executes
- afterAccess() in finally block never called
- Concurrency permit permanently leaked
Solution:
Wrap doExecute() in try-catch block in the concurrency throttle path
and call afterAccess() in catch block to ensure permit is always
released, even when thread creation fails.
The fix only applies to the concurrency throttle path. The
activeThreads-only path does not need fixing because it never calls
beforeAccess(), so there is no permit to leak.
Test approach:
The test simulates thread creation failure and verifies that a
subsequent execution does not deadlock. The first execution should
fail with some exception (type doesn't matter), and the second
execution should complete within timeout if the permit was properly
released.
Signed-off-by: Park Juhyeong <wngud5957@naver.com>
Previously, SingletonSupplier stored "null" in singletonInstance when
the supplied instance was "null". On subsequent get() calls, this was
treated as "uninitialized" and triggered another attempt to obtain an
instance from the Supplier.
This commit ensures that a "null" returned from the instanceSupplier or
defaultSupplier is handled correctly, so that subsequent calls to get()
return "null" consistently instead of repeatedly invoking the Supplier.
Closes gh-35380
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
As of Spring Framework 6.2.13, we support JUnit Jupiter 5.12's
ExtensionContextScope.TEST_METHOD behavior in the SpringExtension and
the BeanOverrideTestExecutionListener; however, users can only benefit
from that if they explicitly set the following configuration parameter
for their entire test suite, which may have adverse effects on other
third-party JUnit Jupiter extensions.
junit.jupiter.extensions.testinstantiation.extensioncontextscope.default=test_method
For Spring Framework 7.0, in order to support dependency injection into
test class constructors and fields in @Nested test class hierarchies
from the same ApplicationContext that is already used to perform
dependency injection into lifecycle and test methods (@BeforeEach,
@AfterEach, @Test, etc.), we have decided to configure the
SpringExtension to use ExtensionContextScope.TEST_METHOD by default. In
addition, we have decided to provide a mechanism for users to switch
back to the legacy "test-class scoped ExtensionContext" behavior in
case third-party TestExecutionListener implementations are not yet
compatible with test-method scoped ExtensionContext and TestContext
semantics.
This commit achieves the above goals as follows.
- A new @SpringExtensionConfig annotation has been introduced, which
allows developers to configure the effective ExtensionContext scope
used by the SpringExtension.
- The SpringExtension now overrides
getTestInstantiationExtensionContextScope() to return
ExtensionContextScope.TEST_METHOD.
- The postProcessTestInstance() and resolveParameter() methods in the
SpringExtension now find the properly scoped ExtensionContext for the
supplied test class, based on whether the @Nested test class
hierarchy is annotated with
@SpringExtensionConfig(useTestClassScopedExtensionContext = true).
See gh-35680
See gh-35716
Closes gh-35697
Previous commit 81ea35c726 in main for 7.0
should have been applied in 6.2.x first for 6.2.1.
This commit applies the changes in 6.2.x as intended,
effective as of 6.2.13.
Closes gh-33974
Although gh-35680 introduced support for JUnit Jupiter's TEST_METHOD
ExtensionContextScope in the SpringExtension and
BeanOverrideTestExecutionListener, those were internal changes that are
not directly visible by TestExecutionListener authors.
However, in order to be compatible with a test-method scoped
TestContext (which takes its values from the current Jupiter
ExtensionContext), existing third-party TestExecutionListener
implementations may need to be modified similar to how
BeanOverrideTestExecutionListener was modified in commit d24a31d469.
To raise awareness of how to deal with such issues, this commit
documents test-method TestContext semantics for TestExecutionListener
authors.
Closes gh-35716
This commit upgrades the build to use Gradle 9.2 and reinstates the use
of the Groovy safe-navigation operator (?.) in framework-api.gradle.
See https://github.com/gradle/gradle/issues/35049
See d038269ec3
Closes gh-35713
Cache resource URLs before sorting to eliminate repeated I/O calls
during comparator operations. The previous implementation called
getURL() multiple times per resource during sorting (O(n log n)
calls), and silently swallowed IOExceptions by returning 0,
potentially causing unstable sort results.
This change:
- Caches URLs once per resource before sorting (O(n) I/O calls)
- Removes unnecessary ArrayList conversions
- Provides clear exception handling with context
- Improves performance by ~70% for typical use cases
Signed-off-by: Park Juhyeong <wngud5957@naver.com>
This commit adapts the MyBeanRegistrar Kotlin code sample to use a
lambda supplier instead of a callable reference since this capability
has been removed.
See gh-35549
Closes gh-35694
Prior to this commit, getPubliclyAccessibleMethodIfPossible() in
ClassUtils incorrectly returned a hidden static method as an
"equivalent" method for a static method with the same signature;
however, a static method cannot be overridden and therefore has no
"equivalent" method in a super type.
To fix that bug, this commit immediately aborts the search for an
"equivalent" publicly accessible method when the original method is a
static method.
See gh-33216
See gh-35189
See gh-35556
Closes gh-35667
Since we now officially support the TEST_METHOD ExtensionContextScope
(see gh-35676 and gh-35680), this commit introduces tests which
demonstrate that the issue raised in gh-34576 is no longer an "issue" if
the user indirectly configures the SpringExtension to use the TEST_METHOD
scope via the "junit.jupiter.extensions.testinstantiation.extensioncontextscope.default"
configuration parameter.
Historically, @Autowired fields in an enclosing class of a @Nested
test class have been injected from the ApplicationContext for the
enclosing class. If the enclosing test class and @Nested test class
share the same ApplicationContext configuration, things work as
developers expect. However, if the enclosing class and @Nested test
class have different ApplicationContexts, that can lead to
difficult-to-debug scenarios. For example, a bean injected into the
enclosing test class will not participate in a test-managed transaction
in the @Nested test class (see gh-34576).
JUnit Jupiter 5.12 introduced a new ExtensionContextScope feature which
allows the SpringExtension to behave the same for @Autowired fields as
it already does for @Autowired arguments in lifecycle and test
methods. Specifically, if a developer sets the ExtensionContextScope to
TEST_METHOD — for example, by configuring the following configuration
parameter as a JVM system property or in a `junit-platform.properties`
file — the SpringExtension already supports dependency injection from
the current, @Nested ApplicationContext in @Autowired fields in an
enclosing class of the @Nested test class.
junit.jupiter.extensions.testinstantiation.extensioncontextscope.default=test_method
However, there are two scenarios that fail as of Spring Framework
6.2.12.
1. @TestConstructor configuration in @Nested class hierarchies.
2. Field injection for bean overrides (such as @MockitoBean) in
@Nested class hierarchies.
Commit 82c34f7b51 fixed the SpringExtension to support scenario #2
above.
To fix scenario #1, this commit revises
BeanOverrideTestExecutionListener's injectField() implementation to
look up the fields to inject for the "current test instance" instead of
for the "current test class".
This commit also introduces tests for both scenarios.
See gh-34576
See gh-35676
Closes gh-35680
This commit updates `JdkClientHttpRequest.TimeoutHandler` javadoc to
reference up-to-date JDK issue that tracks improvements to HTTP client's
request timeout handling.
Closes gh-35581
Signed-off-by: Vedran Pavic <vedran@vedranpavic.com>
Prior to this commit, a regexp path segment ending with a double wilcard
(like "/path**") would be incorrectly parsed as a double wildcard
segment ("/**").
This commit fixes the incorrect parsing.
See gh-35679
Prior to this commit, the `PathPattern` and `PathPatternParser` would
allow multiple-segments matching and capturing with the following:
* "/files/**" (matching 0-N segments until the end)
* "/files/{*path}" (matching 0-N segments until the end and capturing
the value as the "path" variable)
This would be only allowed as the last path element in the pattern and
the parser would reject other combinations.
This commit expands the support and allows multiple segments matching at
the beginning of the path:
* "/**/index.html" (matching 0-N segments from the start)
* "/{*path}/index.html" (matching 0-N segments until the end and capturing
the value as the "path" variable)
This does come with additional restrictions:
1. "/files/**/file.txt" and "/files/{*path}/file.txt" are invalid,
as multiple segment matching is not allowed in the middle of the
pattern.
2. "/{*path}/files/**" is not allowed, as a single "{*path}" or "/**"
element is allowed in a pattern
3. "/{*path}/{folder}/file.txt" "/**/{folder:[a-z]+}/file.txt" are
invalid because only a literal pattern is allowed right after
multiple segments path elements.
Closes gh-35679
This commit improve the reference documentation in order to:
* highlight the deprecation status of `RestTemplate`
* improve the migration guide for `RestClient`, better explaining
possible behavior differences and a migration strategy.
Closes gh-35620
This commit introduces a new isAutowirableConstructor(Executable, PropertyProvider)
overload in TestConstructorUtils and deprecates all other existing variants
for removal in 7.1.
Closes gh-35676
This commit removes JSpecify (TYPE_USE) annotations on
org.hamcrest.Matcher parameters to prevent a related
"Cannot attach type annotations" error when Hamcrest
(optional dependency) is not in the classpath with Java > 22.
Closes gh-35666
This commit uses a MultiValueMap instead of a Map to store bean
registrars, allowing to support multiple bean registrars imported by
the same configuration class.
Closes gh-35653
This commit add a test for multiple bean registrars imported by the same
configuration class.
See gh-35653
Signed-off-by: wakingrufus <wakingrufus@gmail.com>
In previous versions, HttpStatus.resolve (or valueOf) always returned
non-deprecated HTTP status for given code. This was ensured implicitly,
by placing non-deprecated enum entries before their respective
deprecations. This was not ensured for 413 Content Too Large.
See gh-35659
Signed-off-by: Damian Malczewski <damian.m.malczewski@gmail.com>
Prior to this commit, gh-35225 introduced HTTP response body
decompression support for "gzip" and "deflate" encodings for the
`JdkClientHttpRequestFactory`.
While body decompression works, the client keeps the "Content-Encoding"
and "Content-Length" response headers intact, which misleads further
response handling: the body size has changed and it is not compressed
anymore.
This commit ensures that the relevant response headers are removed from
the HTTP response after decompression.
Fixes gh-35668
This commit replaces ParameterizedTypeReference and ResolvableType
target type customization with the lambda by directly exposing
ParameterizedTypeReference methods at top level, as generics
variants of the class-based existing ones.
Closes gh-35635
Prior to this commit, Spring Framework would ship several abstract
`*View` implementations for rendering PDF, RSS or XLS documents using
well-known libraries. More recently, supporting libraries evolved a lot
with new versions and forks. Spring Framework is not in a position to
efficiently support all variants within the project.
This commit deprecates the relevant classes. Instead, libraries can
reuse existing code and ship optional support for Spring directly.
Often, updating imports and library usage is enough.
As an alternative, applications can decide to perform rendering
direclty in web handlers.
Closes gh-35451
Thanks to a proposal from @wilkinsona, this commit introduces a
try-catch block in loadBeanDefinitions(...) which throws an
IllegalStateException that provides context regarding the configuration
class and cause of the failure.
Closes gh-35631
Co-authored-by: Andy Wilkinson <andy.wilkinson@broadcom.com>
As reported in gh-34651, `DataBuffer#getByte` can be inefficient for
some implementations, as bound checks are performed for each call.
This commit introduces a new `forEachByte` method that helps with
traversing operations without paying the bound check cost for each byte.
Closes gh-35623
This commit rejects the invocation of an effectively private handler
method on a CGLIB proxied controller for both Spring MVC and Spring
WebFlux.
Closes gh-35352
Co-authored-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>
Signed-off-by: Yongjun Hong <kevin0928@naver.com>
Signed-off-by: yongjunhong <yongjunh@apache.org>
Prior to this commit, the non-pattern package prefix check used
packageName.startsWith(basePackage) which incorrectly treats
"com.example2.foo" as a subpackage of "com.example".
Closes gh-35601
Signed-off-by: NeatGuyCoding <15627489+NeatGuyCoding@users.noreply.github.com>
Prior to this commit, our @Retryable support as well as a RetryPolicy
created by the RetryPolicy.Builder only matched against top-level
exceptions when filtering included/excluded exceptions thrown by a
@Retryable method or Retryable operation.
With this commit, we now match against not only top-level exceptions
but also nested causes within those top-level exceptions. This is
achieved via the new ExceptionTypeFilter.match(Throwable, boolean)
support.
See gh-35592
Closes gh-35583
Prior to this commit, ExceptionTypeFilter only provided support for
filtering based on exact matches against exception types; however, some
use cases require that filtering be applied to nested causes in a given
exception. For example, this functionality is a prerequisite for
gh-35583.
This commit introduces a new match(Throwable, boolean) method in
ExceptionTypeFilter, where the boolean flag enables matching against
nested exceptions.
See gh-35583
Closes gh-35592
Prior to this commit, ReactorResourceFactory was not restarted properly
when the ApplicationContext was resumed by the TestContext Framework
after a context pause. The reason is that the managed LoopResources
were disposed when ConfigurableApplicationContext.pause() was invoked
and reacquired when ConfigurableApplicationContext.restart() was
invoked.
To address that, this commit overrides isPauseable() in
ReactorResourceFactory to return false, thereby avoiding participation
in pause scenarios.
Closes gh-35585
Internally maintain a chain of HttpMessageConverters.ClientBuilder
consumers in addition to the List of converters.
List based methods apply to the list.
HttpMessageConverters based methods are composed into a Consumer.
At build() time prepare a single HttpMessageConverters.ClientBuilder.
Insert list based converters first.
Apply HttpMessageConverters consumers after that.
Deprecate both List methods. Eventually, HttpMessageConverters should
be the main mechanism. In the mean time we layer them as described.
Closes gh-35578
Compose consumers and apply them together from the build method
to allow multiple parties to supply consumers that collaborate
on the same HttpMessageConverters.Builder.
See gh-35578
Prior to this commit, the BeanOverrideBeanFactoryPostProcessor rejected
any attempt to override a non-singleton bean; however, due to interest
from the community, we have decided to provide support for overriding
non-singleton beans via the Bean Override mechanism — for example, when
using @MockitoBean, @MockitoSpyBean, and @TestBean.
With this commit, we now support Bean Overrides for non-singletons: for
standard JVM runtimes as well as AOT processing and AOT runtimes. This
commit also documents that non-singletons will effectively be converted
to singletons when overridden and logs a warning similar to the
following.
WARN: BeanOverrideBeanFactoryPostProcessor - Converting 'prototype' scoped bean definition 'myBean' to a singleton.
See gh-33602
See gh-32933
See gh-33800
Closes gh-35574
This commit introduces a new findAnnotatedBeans(ListableBeanFactory)
override for the existing findAnnotatedBeans(ApplicationContext) method.
Closes gh-35571
AbstractApplicationContext.applicationStartup can only be injected after the instance construction. This metrics point has no practical effect at present and can be removed safely.
Closes gh-35570
Signed-off-by: Wars <wars@wars.cat>
This commit introduces two tests to verify the status quo.
- mapAccessThroughIndexerForNonexistentKey(): demonstrates that map
access via the built-in support in the Indexer returns `null` for a
nonexistent key.
- nullAwareMapAccessor(): demonstrates that users can implement and
register a custom extension of MapAccessor which reports that it can
read any map (ignoring whether the map actually contains an entry for
the given key) and returns `null` for a nonexistent key.
See gh-35534
Prior to this commit, a NoUniqueBeanDefinitionException was thrown when
multiple primary beans were detected within a given set of beans, but
nothing was logged. For use cases where the exception is handled by
infrastructure code, it may not be obvious to the developer what the
problem is.
To address that, a TRACE message is now logged whenever multiple
competing primary beans are detected in DefaultListableBeanFactory.
Closes gh-35550
After further consideration, we have decided to revert the
nullability changes in the reactive TransactionCallback and
TransactionalOperator.
See gh-35561
Prior to this commit, configuring a custom `StringHttpMessageConverter`
would be overwritten when the `registerDefaults()` option is enabled.
Fixes gh-35563
This commit adds a reproducer for the change of behavior introduced via
https://youtrack.jetbrains.com/issue/KT-76667. The test is only broken
with Kotlin 2.2.20+ without the related fix (see previous commit).
Closes gh-35487
SingletonSupplier<T> supplier-based static methods nullability should
be refined to accept in a flexible way nullable or non-nullable T.
Closes gh-35559
Previously, if a ConfigurationBeanNameGenerator is used to parse
configuration classes, it is not invoked for `Bean` methods that provide
a specific bean name. This doesn't give a chance to an implementation to
tune such a bean, if required.
This commit updates the signature of ConfigurationBeanNameGenerator to
provide the identified bean name on the `@Bean` declaration,if any, and
to always invoke it.
Closes gh-35505
At some point, TestNG started implementing listener methods as interface
default methods, so we no longer need to override those methods with
empty implementations.
Prior to this commit, AbstractTestNGSpringContextTests was not
thread-safe with regard to tracked exceptions.
To address that, AbstractTestNGSpringContextTests now tracks the test
exception via a ThreadLocal.
Closes gh-35528
Prior to this commit, the MapAccessor for SpEL resided in the
org.springframework.context.expression package in the spring-context
module; however, it arguably should reside in the spring-expression
module so that it can be used whenever SpEL is used (without requiring
spring-context).
This commit therefore officially deprecates the MapAccessor in
spring-context for removal in favor of a new copy of the implementation
in the org.springframework.expression.spel.support package in the
spring-expression module.
Closes gh-35537
This commit adds new `GsonEncoder` and `GsonDecoder` for serializing and
deserializing JSON in a reactive fashion.
Because `Gson` itslef does not support decoding JSON in a non-blocking
way, the `GsonDecoder` does not support decoding to `Flux<*>` types.
Closes gh-27131
This commit reinstantiates checks for kotlin-reflect (via static final
fields for faster Java code paths and better native code removal) which
were removed as part of gh-34275, which did not consider the
increasingly popular use cases where kotlin-stdlib is present in the
classpath as a transitive dependency in Java applications.
Closes gh-35511
As a follow-up to gh-35461 and a comment left on the Spring Blog, we
have decided to prevent empty declarations of @ConcurrencyLimit,
thereby requiring users to explicitly declare the value for the limit.
Closes gh-35523
This commit introduces a new `limit` attribute in @ConcurrencyLimit as
an alias for the existing `value` attribute. This commit also renames
the `valueString` attribute to `limitString`.
See gh-35461
See gh-35470
Prior to this commit, the `IntrospectingClientHttpResponse` would try
and read the HTTP response stream in order to check for the presence of
a non-empty message body.
Developers reported that in some cases, an `EOFException` is thrown
instead of returning -1 from the `read()` method. This commit ensures
that this case is taken into account and that we report the response as
an empty body in these cases.
Closes gh-35361
This commit upgrades the build to use Gradle 9.1.
To achieve that, the following changes were necessary.
- Stop using Groovy safe-navigation operator (?.) in
framework-api.gradle due to a NullPointerException.
- Switch from the io.github.goooler.shadow plugin to the
com.gradleup.shadow plugin, since the former is no longer maintained
and the latter is a fork that replaces it.
Closes gh-35508
This commit fixes code generation for a bean produced by a protected
factory method. Previously only the code generated for public methods,
i.e. without a dedicated instance supplier method, was handled.
Closes gh-35486
This commit apply several refinements to PropagationContextElement:
- Capture the ThreadLocal when instantiating the
PropagationContextElement in order to support dispatchers switching
threads
- Remove the constructor parameter which is not idiomatic and breaks
the support when switching threads, and use instead the
updateThreadContext(context: CoroutineContext) parameter
- Make the kotlinx-coroutines-reactor dependency optional
- Make the properties private
The Javadoc and tests are also updated to use the
`Dispatchers.IO + PropagationContextElement()` pattern performed
outside of the suspending lambda, which is the typical use case.
Closes gh-35469
This commit adds support for Hibernate 7.1+ SqmQueryImpl class in
EntityManagerRuntimeHints, keeps the support for the former
QuerySqmImpl class for Hibernate 7.0 compatibility and adds a
related test.
Closes gh-35462
Prior to this commit, annotations were not found on parameters in an
overridden method unless the method was public. Specifically, the
search algorithm in AnnotatedMethod did not consider a protected or
package-private method in a superclass to be a potential override
candidate. This affects parameter annotation searches in
spring-messaging, spring-webmvc, spring-webflux, and any other
components that use or extend AnnotatedMethod.
To address that, this commit revises the search algorithm in
AnnotatedMethod to consider all non-final declared methods as potential
override candidates, thereby aligning with the search logic in
AnnotationsScanner for the MergedAnnotations API.
Closes gh-35349
Prior to this commit, the Micrometer context-propagation project would
help propagating information from `ThreadLocal`, Reactor `Context` and
other context objects. This is already well supported for Micrometer
Observations.
In the case of Kotlin suspending functions, the processing of tasks
would not necessarily update the `ThreadLocal` when the function is
scheduled on a different thread.
This commit introduces the `PropagationContextElement` operator that
connects the `ThreadLocal`, Reactor `Context` and Coroutine `Context`
for all libraries using the "context-propagation" project.
Applications must manually use this operator in suspending functions
like so:
```
suspend fun suspendingFunction() {
return withContext(PropagationContextElement(currentCoroutineContext())) {
logger.info("Suspending function with traceId")
}
}
```
Closes gh-35185
This commit refines the JSP view resolver documentation contribution
by using tabs for Java and XML configuration, with Java displayed by
default.
Closes gh-35444
Prior to this commit, a RetryException thrown for an
InterruptedException returned the wrong value from getRetryCount().
Specifically, the count was one more than it should have been, since the
suppressed exception list contains the initial exception as well as all
retry attempt exceptions.
To address that, this commit introduces an internal
RetryInterruptedException which accounts for this off-by-one error.
Closes gh-35434
In RetryTemplate, if we encounter an InterruptedException while
sleeping for the configured back-off duration, we throw a
RetryException with the InterruptedException as the cause.
However, prior to this commit, that RetryException propagated to the
caller without notifying the registered RetryListener.
To address that, this commit introduces a new
onRetryPolicyInterruption() callback in RetryListener as a companion to
the existing onRetryPolicyExhaustion() callback.
Closes gh-35442
In RetryTemplate, if we encounter an InterruptedException while
sleeping for the configured back-off duration, we throw a
RetryException with the InterruptedException as the cause.
However, in contrast to the specification for RetryException, we do not
currently include the exceptions for previous retry attempts as
suppressed exceptions in the RetryException which is thrown in such
scenarios.
In order to comply with the documented contract for RetryException,
this commit includes exceptions for previous attempts in the
RetryException thrown for an InterruptedException as well.
Closes gh-35434
Prior to this commit, we included the initial exception in the log
message for the initial invocation of a retryable operation; however,
we did not include the current exception in the log message for
subsequent attempts.
For consistency, we now include the current exception in log messages
for subsequent retry attempts as well.
Closes gh-35433
Since Spring Framework 4.2, DefaultContextCache supported an LRU (least
recently used) eviction policy via a custom LruCache which extended
LinkedHashMap. The LruCache reacted to LinkedHashMap's
removeEldestEntry() callback to remove the LRU context if the maxSize
of the cache was exceeded.
Due to the nature of the implementation in LinkedHashMap, the
removeEldestEntry() callback is invoked after a new entry has been
stored to the map.
Consequently, a Spring ApplicationContext (C1) was evicted from the
cache after a new context (C2) was loaded and added to the cache,
leading to failure scenarios such as the following.
- C1 and C2 share an external resource -- for example, a database.
- C2 initializes the external resource with test data when C2 is loaded.
- C1 cleans up the external resource when C1 is closed.
- C1 is loaded and added to the cache.
- C2 is loaded and added to the cache before C1 is evicted.
- C1 is evicted and closed.
- C2 tests fail, because C1 removed test data required for C2.
To address such scenarios, this commit replaces the custom LruCache
with custom LRU eviction logic in DefaultContextCache and revises
the put(MergedContextConfiguration, ApplicationContext) method to
delegate to a new evictLruContextIfNecessary() method.
This commit also introduces a new put(MergedContextConfiguration,
LoadFunction) method in the ContextCache API which is overridden by
DefaultContextCache to ensure that an evicted context is removed and
closed before a new context is loaded to take its place in the cache.
In addition, DefaultCacheAwareContextLoaderDelegate has been revised to
make use of the new put(MergedContextConfiguration, LoadFunction) API.
Closes gh-21007
Prior to this commit, gh-32097 added native support for Jetty for both
client and server integrations. The `JettyDataBufferFactory` was
promoted as a first class citizen, extracted from a private class in the
client support. To accomodate with server-side requirements, an extra
`buffer.retain()` call was performed.
While this is useful for server-side support, this introduced a bug in
the data buffer factory, as wrapping an existing chunk means that this
chunk is already retained.
This commit fixes the buffer factory implementation and moved existing
tests from mocks to actual pooled buffer implementations from Jetty.
The extra `buffer.retain()` is now done from the server support, right
before wrapping the buffer.
Fixes gh-35319
As of gh-33616, Spring now supports metadata reading with the ClassFile
API on JDK 24+ runtimes. This commit fixes a bug where
`ArrayStoreException` were thrown when reading annotation attribute
values for arrays.
Fixes gh-35252
This commit ensures that the "Accept-Encoding" header is present for HTTP
requests sent by the `JdkClientHttpRequestFactory`. Only "gzip" and
"deflate" encodings are supported.
This also adds a custom `BodyHandler` that decompresses HTTP response
bodies if the "Content-Encoding" header lists a supported variant.
This feature is enabled by default and can be disabled on the request
factory.
See gh-35225
Signed-off-by: spicydev <vivek@mirchi.dev>
[brian.clozel@broadcom.com: squash commits]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
This commit updates the `HttpStatus` enum with the latest changes in
RFC9110:
* deprecate "413 Payload Too Large" in favor of "413 Content Too Large"
* deprecate "418 I'm a teapot" as it was meant as a joke and is now
marked as unused
* Introduce new "421 Misdirected Request"
* deprecate "422 Unprocessable Entity" in favor of
"422 Unprocessable Content"
* deprecate "509 Bandwidth Limit Exceeded" as it's now unassigned
* deprecate "510 Not Extended" as it's now marked as "historic"
The relevant exceptions, test matchers and more have been updated as a
result.
Closes gh-32870
This commit mames `StartupStep` extend `AutoCloseable` in order to allow
the try/with resources syntax and making the `step.end()` call
transparent.
Closes gh-35277
This commit updates Jackson 3 JSON support to use JsonMapper
instead of ObjectMapper in converters, codecs and view constructors.
As a consequence, AbstractJacksonDecoder, AbstractJacksonEncoder,
AbstractJacksonHttpMessageConverter and JacksonCodecSupport are
now parameterized with <T extends ObjectMapper>.
Closes gh-35282
This commit reorders and clarifies the usage instructions for
ApplicationEvents to:
1. Recommend method parameter injection as the primary approach, since
ApplicationEvents has a per-method lifecycle
2. Clarify that ApplicationEvents is not a general Spring bean and
cannot be constructor-injected
3. Explicitly state that field injection is an alternative approach
This addresses confusion where developers expect ApplicationEvents to
behave like a regular Spring bean eligible for constructor injection.
See gh-35297
Closes gh-35335
Signed-off-by: khj68 <junthewise@gmail.com>
Adds an ObservationDocumentation and ObservationConvention implementation
that follows the OpenTelemetry semantic convention for HTTP Server
metrics and spans.
See gh-35358
Undertow does not support Servlet 6.1, we need to remove compatibility
tests as well as Undertow-specific classes for WebSocket and reactive
support.
Closes gh-35354
Prior to this commit, the MergedAnnotations support (specifically
AnnotationsScanner) and AnnotatedMethod did not find annotations on
overridden methods in type hierarchies with unresolved generics.
The reason for this is that ResolvableType.resolve() returns null for
such an unresolved type, which prevents the search algorithms from
considering such methods as override candidates.
For example, given the following type hierarchy, the compiler does not
generate a method corresponding to processOneAndTwo(Long, String) for
GenericInterfaceImpl. Nonetheless, one would expect an invocation of
processOneAndTwo(Long, String) to be @Transactional since it is
effectively an invocation of processOneAndTwo(Long, C) in
GenericAbstractSuperclass, which overrides/implements
processOneAndTwo(A, B) in GenericInterface, which is annotated with
@Transactional.
However, the MergedAnnotations infrastructure currently does not
determine that processOneAndTwo(Long, C) is @Transactional since it is
not able to determine that processOneAndTwo(Long, C) overrides
processOneAndTwo(A, B) because of the unresolved generic C.
interface GenericInterface<A, B> {
@Transactional
void processOneAndTwo(A value1, B value2);
}
abstract class GenericAbstractSuperclass<C> implements GenericInterface<Long, C> {
@Override
public void processOneAndTwo(Long value1, C value2) {
}
}
static GenericInterfaceImpl extends GenericAbstractSuperclass<String> {
}
To address such issues, this commit changes the logic in
AnnotationsScanner.hasSameGenericTypeParameters() and
AnnotatedMethod.isOverrideFor() so that they use
ResolvableType.toClass() instead of ResolvableType.resolve(). The
former returns Object.class for an unresolved generic which in turn
allows the search algorithms to properly detect method overrides in
such type hierarchies.
Closes gh-35342
Prior to this commit, a regexp path segment ending with a double wilcard
(like "/path**") would be incorrectly parsed as a double wildcard
segment ("/**").
This commit fixes the incorrect parsing.
Fixes gh-35339
Prior to this commit, RetryTemplate supplied the wrong exception to
RetryListener.onRetryPolicyExhaustion(). Specifically, the execute()
method in RetryTemplate supplied the final, composite RetryException to
onRetryPolicyExhaustion() instead of the last exception thrown by the
Retryable operation.
This commit fixes that bug by ensuring that the last exception thrown by
the Retryable operation is supplied to onRetryPolicyExhaustion().
Closes gh-35334
This commit simplifies RetryException to always require a root cause
and mark it as not nullable. Such exception is the exception thrown by
the retryable operation and should always be available as it explains
why the invocation was a candidate for retrying in the first place.
Closes gh-35332
This enhancement enables finer control over interceptor application
based on HTTP methods, aligning with modern Spring 7.x practices.
- Extend MappedInterceptor with include/exclude HTTP methods
- Add constructors for interceptor implementations
- Update InterceptorRegistration with fluent methods
- Keep existing constructors and methods for compatibility
- Update matches() to check HTTP method conditions
See gh-35273
Signed-off-by: SRIRAM9487 <sriram9487tk@gmail.com>
Prior to this commit, ScriptUtils.executeSqlScript() treated every
statement within the script as if it were a single insert/update/delete
statement. This disregarded the fact that the execution of a JDBC
Statement can result in multiple individual statements, some of which
result in a ResultSet and others that result in an update count.
For example, when executing a stored procedure on Sybase, ScriptUtils
did not execute all statements within the stored procedure.
To address that, this commit revises the implementation of
ScriptUtils.executeSqlScript() so that it handles multiple results and
differentiates between result sets and update counts.
Closes gh-35248
Handle CancellationException in order to throw an HttpTimeoutException
when the timeout handler caused the cancellation.
See gh-34721
Signed-off-by: giampaolo <giampaorr@gmail.com>
fix: use timeoutHandler with a flag isTimeout
Closes gh-33973
Signed-off-by: giampaolo <giampaorr@gmail.com>
Taken into account by all proxy processors, this enables consistent proxy type defaulting in Spring Boot as well as consistent opting out for specific bean definitions.
Closes gh-35286
Closes gh-35293
Prior to this commit, the `JmsTemplate` would use `MessagePostProcessor`
for mutating JMS messages before they are being sent, but only if the
method takes a post processor as an argument.
The main use case so far is to mutate messages after they've been
created by a `MessageConverter` from a payload.
This commit updates the `JmsClient` to use `MessagePostProcessor` more
broadly, for all outgoing messages (converted or not). This brings an
interception-like mechanism for clients to enrich the message before
being sent.
This change also updates the `JmsClient` static factories and
introduces a Builder, allowing for more configuration options: multiple
message converters and message post processors.
Closes gh-35271
to AbstractClientHttpServiceRegistrar since it is a registrar and
an extension of Abstract[HttpServiceRegistrar]. Also, a more
friendly name for use in application configuration.
See gh-35244
The detect methods in the GroupRegistry that find all interfaces
with HttpExchange annotations now exclude HttpServiceClient
interfaces that are instead supported by a dedicated registrar.
This ensures there is no overlap between the HttpServiceClient
registrar scan and the ImportHttpServices registrar scan or
the scan of any other custom registrar.
See gh-35244
Refine the StringUtils#uriDecode method in the following ways:
- Use a StringBuilder instead of ByteArrayOutputStream, and only decode
%-encoded sequences.
- Use HexFormat.fromHexDigits to decode hex sequences.
- Decode to a byte array that is only allocated if encoded sequences are
encountered.
This commit adds another optimization mainly for the use case where
there is no encoded sequence, and updates the Javadoc of both
StringUtils#uriDecode and UriUtils#decode to match the implementation.
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Co-Authored-by: Sebastien Deleuze <sebastien.deleuze@broadcom.com>
Closes gh-35253
This commit ensures that the original request URI is displayed in
`NoResourceFoundException` error messages when logged. Without this
change, it can be confusing to see only the attempted resource path.
There are cases where the original request was not meant for resource
handling and we want to understand why this wasn't processed by another
handler.
The Problem Detail attribute has not been changed as the "instance"
attribute already displays the request path.
Closes gh-34553
Prior to this commit, the `PathPattern` and `PathPatternParser` would
allow multiple-segments matching and capturing with the following:
* "/files/**" (matching 0-N segments until the end)
* "/files/{*path}" (matching 0-N segments until the end and capturing
the value as the "path" variable)
This would be only allowed as the last path element in the pattern and
the parser would reject other combinations.
This commit expands the support and allows multiple segments matching at
the beginning of the path:
* "/**/index.html" (matching 0-N segments from the start)
* "/{*path}/index.html" (matching 0-N segments until the end and capturing
the value as the "path" variable)
This does come with additional restrictions:
1. "/files/**/file.txt" and "/files/{*path}/file.txt" are invalid,
as multiple segment matching is not allowed in the middle of the
pattern.
2. "/{*path}/files/**" is not allowed, as a single "{*path}" or "/**"
element is allowed in a pattern
3. "/{*path}/{folder}/file.txt" "/**/{folder:[a-z]+}/file.txt" are
invalid because only a literal pattern is allowed right after
multiple segments path elements.
Closes gh-35213
This commit replaces the Mockito agent configuration with a single
bytebuddy agent configuration that addresses both Mockito and mockk on
tests.
Closes gh-35207
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
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
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
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>
This commit aligns `HttpMessageConverters` with the WebFlux codecs
configuration by adding custom converters first, before the
auto-detected and well-known ones.
This is a general approach in Spring Framework, where custom
implementations are more likely to handle specific uses cases and should
be involved before considering the more general implementations.
Fixes gh-35177
In order to improve the user experience with URLs for sections of the
Validation chapter, this commit makes the following changes to page
names in the "validation" folder.
- beans-beans.html --> data-binding.html
- conversion.html --> error-code-resolution.html
Some of the section anchors in data-binding.html have also been
renamed. For example, #beans-beans is now #data-binding-property-binding.
Closes gh-35181
If an application depends on automatic type conversion from
java.time.Instant to java.sql.Timestamp, the ObjectToObjectConverter
performs the conversion based on convention, by using reflection to
invoke Timestamp.from(Instant).
However, when running in a native image a user needs to explicitly
register runtime hints for that particular use of reflection.
To assist users who are running their applications in a native image,
this commit automatically registers the necessary runtime hints for
Timestamp.from(Instant) so that users do not have to.
See gh-35175
Closes gh-35156
In order to avoid unnecessary use of reflection and to simplify native
image deployments, this commit introduces explicit support for
automatic conversions from java.util.Date to java.time.Instant and vice
versa.
To achieve that, this commit introduces an InstantToDateConverter and a
DateToInstantConverter and registers them automatically in
DefaultConversionService.
See gh-35156
Closes gh-35175
This commit leverages flexible generics nullness at method and
type level when relevant in spring-jdbc.
Due to https://github.com/uber/NullAway/issues/1075, some related
`@SuppressWarnings("NullAway")` have been added.
JdbcOperations Kotlin extensions have been refined accordingly.
Closes gh-34911
After the upgrade to Selenium 4.33.0 in commit 1051592ae8, the
spring-test module began to fail as follows.
/home/runner/.gradle/caches/modules-2/files-2.1/io.projectreactor/reactor-core/3.8.0-M4/3195c7882f5833915a74ee18d58857cabc29b4c6/reactor-core-3.8.0-M4.jar(/reactor/util/annotation/Nullable.class):
warning: Cannot find annotation method 'when()' in type 'Nonnull':
class file for javax.annotation.Nonnull not found
warning: unknown enum constant When.MAYBE
reason: class file for javax.annotation.meta.When not found
error: warnings found and -Werror specified
1 error
2 warnings
To address that, this commit introduces a compileOnly dependency on
"com.google.code.findbugs:jsr305".
Previously, @RequestBody(required = false) annotations declared
on interface methods were ignored when resolving the consumes
condition. This caused mappings to incorrectly require a request
body with a Content-Type such as application/json, even when no
body was provided.
This change uses AnnotatedMethod to retrieve parameter annotations
from both the implementation and its interfaces, ensuring that the
required flag is respected and body presence is evaluated correctly.
Closes gh-35086
Signed-off-by: Renato Mameli <renatomamel410@gmail.com>
Comparing to Java's `BeanFactory.getBean(Class<T> requiredType)`, Kotlin's `BeanFactory.getBean<T>()` supports generic type as `T`, this commit add test to cover that and add assertions.
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
The @CacheConfig section of the reference manual provides an example
that declares @CacheConfig("books").
However, unlike the @Cacheable, @CachePut, and @CacheEvict
annotations, @CacheConfig currently does not have a `value` alias for
the `cacheNames` attribute. Thus, the example in the reference manual
does not compile, and @CacheConfig(cacheNames = "books") would be the
supported way to declare that.
The driving factor for this commit is therefore to provide a simplified
and consistent programming model for users that only need to define
default cache names at the type level (like in the existing example in
the reference manual).
To address that, this commit introduces a `value` alias for
`cacheNames` in @CacheConfig.
See gh-35096
Closes gh-35152
(cherry picked from commit 6091453feb)
Prior to this commit, AbstractAutowireCapableBeanFactory's
initializeBean() method always attempted to initialize a NullBean.
However, invokeInitMethods() (which is invoked by initializeBean())
skips processing of a NullBean, which is logical since a NullBean will
never contain init-methods.
In practice, initialization and post-processing of a NullBean should
not result in any change to the NullBean.
This commit therefore skips initialization of a NullBean altogether.
Closes gh-35165
In commit 97522cfa36, I implemented a
short-circuiting matching algorithm in DefaultRetryPolicy for includes
and excludes, which was later copied to MethodRetrySpec.
After we switched to using ExceptionTypeFilter, I realized that the
matching algorithm in InstanceFilter (the superclass of
ExceptionTypeFilter) does not exhibit the same short-circuiting
characteristics.
In light of that, this commit revises the matching algorithm in
InstanceFilter to mirror the original short-circuiting algorithm in
DefaultRetryPolicy.
See gh-35058
See gh-35109
See gh-35160
Closes gh-35161
Prior to this commit, ExceptionTypeFilter only supported matching
against an exception type. However, most use cases involve matching
against an exception instance. Moreover, every use case within the core
Spring Framework uses ExceptionTypeFilter to match against concrete
exception instances.
This commit therefore introduces an overloaded match(Throwable) method
in ExceptionTypeFilter in order to provide support for the most common
use cases.
See gh-35109
Closes gh-35160
Prior to this commit, the constructors for InstanceFilter and
ExceptionTypeFilter required one to supply the matchIfEmpty flag.
However, users will typically want that to be true. Moreover, we always
supply true for the matchIfEmpty flag within the Spring Framework.
This commit therefore makes the matchIfEmpty flag optional by
introducing overloaded constructors for InstanceFilter and
ExceptionTypeFilter that only accept the includes and excludes
collections.
In addition, this commit overhauls the Javadoc for InstanceFilter and
ExceptionTypeFilter, fixing several issues in the documentation.
Furthermore, this commit applies consistent @Nullable declarations
in ExceptionTypeFilter.
Closes gh-35158
Prior to this commit, the value attribute in @Contract was declared as
follows.
String value() default "";
That allowed empty declarations such as @Contract or @Contract();
however, a contract is not useful without declared constraints.
To address that, this commit removes the `default ""` declaration in
order to force users to provide explicit constraints.
Although one could technically still declare the annotation without
constraints via @Contract(""), it's unlikely that anyone would
intentionally do that.
Closes gh-35157
This allows autowiring a MockServerSpec in test class and using a different
identity or none at all with each test.
Polishing in MockServerSpecTests.
See gh-35042
Prior to this commit @CacheConfig did not have a `value` attribute
alias for `cacheNames`, even though the rest of the cache-related
annotations (such as @Cacheable, @CachePut, etc.) do have a `value` /
`cacheNames` alias pair.
To address that inconsistency, this commit introduces a `value` alias
for `cacheNames` in @CacheConfig as well.
See gh-35096
Closes gh-35152
This commit reduces code duplication by reusing the logic already
available in ExceptionTypeFilter.
Closes gh-35109
Signed-off-by: Mengqi Xu <2663479778@qq.com>
This commit refines the null-safety documentation to document more
explicitly the code style guidelines related to
`@Target(ElementType.TYPE_USE)`.
Closes gh-35098
When the core retry functionality was introduced, it had a built-in
MaxRetryDurationPolicy. In #35058, that was migrated to a
withMaxDuration() factory method, and in #35110 that was renamed to
withMaxElapsedTime() (with a corresponding maxElapsedTime() method on
the builder) in order to align with the maxElapsedTime feature of
ExponentialBackOff. The latter also changed the semantics of the
feature in the context of the RetryPolicy.
However, @Retryable does not provide maxElapsedTime support.
In addition, the maxElapsedTime feature is a bit misleading, since it
does not actually track CPU time or wall-clock time but rather only the
sum of individual, accumulated back-off intervals/delays, which is
likely not very useful. Furthermore, the maxElapsedTime will never
apply to a zero-valued delay/interval.
In light of the above, this commit removes the maxElapsedTime support
from the built-in RetryPolicy.
Users can still implement a custom BackOff strategy if they find they
need some form of "max elapsed time" or "max duration".
See gh-34716
See gh-35058
See gh-34529
See gh-35110
Closes gh-35144
Moves @Retryable infrastructure to resilience package in spring-context module.
Includes duration parsing and placeholder resolution for @Retryable attributes.
Provides convenient @EnableResilientMethods for @Retryable + @ConcurrencyLimit.
Closes gh-35133
See gh-34529
Update `SpringFactoriesLoader` so that the cache stores only the
factories and not the complete loader.
Prior to this commit, if a cache entry was added with the thread
context classloader, the loader instance would be added and the
classloader stored. If the thread context classloader subsequently
changes, and a call is made to `forDefaultResourceLocation` with
`null` for the classloader, the cached entry would be used which
contains the older classloader.
Closes gh-34732
The compiler has a constants pool limit of 65536 entries per source file
which can be hit with a very large amount of beans to register in the
bean factory.
This commit makes sure to create separate source files if the number
of beans to register is very large. The main generated source file
delegate to those.
Closes gh-35044
This commit simplifies our dependency management for JUnit artifacts by
making use of the junit-jupiter and junit-platform-suite aggregator
artifacts.
Closes gh-35127
After experimenting with our newly introduced core retry support
(RetryPolicy, RetryTemplate, etc.) and @Retryable support, it
became apparent that there are overlapping concerns between the current
RetryPolicy and BackOff contracts.
- RetryPolicy and BackOff both have stateful executions: RetryExecution
and BackOffExecution. However, only one stateful execution is
necessary.
- FixedBackOff and ExponentialBackOff already incorporate "retry" logic
in terms of max attempts, max elapsed time, etc. Thus, there is no
need to duplicate such behavior in a RetryPolicy and its
RetryExecution.
- RetryTemplate currently accepts both a RetryPolicy and a BackOff in
order to instrument the retry algorithm. However, users would
probably rather focus on configuring all "retry" logic via a single
mechanism.
In light of the above, this commit directly incorporates BackOff
in RetryPolicy as follows.
- Remove the RetryExecution interface and move its shouldRetry() method
to RetryPolicy, replacing the current RetryExecution start() method.
- Introduce a default getBackOff() method in the RetryPolicy interface.
- Introduce RetryPolicy.withDefaults() factory method.
- Completely overhaul the RetryPolicy.Builder to provide support for
configuring a BackOff strategy.
- Remove BackOff configuration from RetryTemplate.
- Revise the method signatures of callbacks in RetryListener.
The collective result of these changes can be witnessed in the
reworked implementation of AbstractRetryInterceptor.
RetryPolicy retryPolicy = RetryPolicy.builder()
.includes(spec.includes())
.excludes(spec.excludes())
.predicate(spec.predicate().forMethod(method))
.maxAttempts(spec.maxAttempts())
.delay(Duration.ofMillis(spec.delay()))
.maxDelay(Duration.ofMillis(spec.maxDelay()))
.jitter(Duration.ofMillis(spec.jitter()))
.multiplier(spec.multiplier())
.build();
RetryTemplate retryTemplate = new RetryTemplate(retryPolicy);
See gh-34716
See gh-34529
See gh-35058
Closes gh-35110
Prior to this commit, `WebMvcConfigurationSupport` would configure file
extensions/media types registrations based on classpath detection.
Since gh-33894, the detection of message converters is located in a
single place, `HttpMessageConverters`.
This commit updates the `WebMvcConfigurationSupport` to use the actual
message converters configured to decide which file extensions should be
set up for content negotiation.
See gh-33894
Prior to this commit, the classpath detection of various
`HttpMessageConverter` types was using an instance `ClassLoader`. The
main goal here was to provide the feature and being able to test it with
filtered classloaders.
It seems this approach fails with GraalVM and we need to ensure that
classpath detection is performed at class loading time for our GraalVM
feature (inlining such static booleans at build time).
As a result, we need to remove the tests for classpath detection.
See gh-33894
This commit uses the new `HttpMessageConverters` class for the HTTP
client (`RestTemplate` and `RestClient`) and HTTP server support.
This effectively removes the duplication of classpath detection for
message converters in multiple places: clients, server and the multipart
converter itself.
Instead of creating multiple instances of the same converters, this
allows applications to share converter instances as much as possible for
better memory efficiency.
As a result, this change also deprecates configuration methods in the
MVC support that are superseded by the new methods introduced for
`HttpMessageConverters` support.
Closes gh-33894
Prior to this commit, Spring Web would configure
`HttpMessageConverter<?>` collections on clients like `RestTemplate` and
on the server infrastructure, in `WebMvcConfigurationSupport`.
This commit introduces a high-level construct for building and
configuring ordered collections of converters.
This includes:
* configuration of well-known converters with classpath detection
* configuration of shared converters, or client/server specific
* configuration of custom converters
See gh-33894
gh-33616 refactored `CachingMetadataReaderFactory` and broke the
behavior as it bypassed the cache for `getMetadataReader(String
className)` operations.
This commit restores the original behavior.
Fixes gh-35112
This commit allows RestClient to handle StreamingHttpOutputMessage
properly by checking the type of the request and invoking setBody()
when appropriate. This improves interoperability with components that
expect streamed output.
A new integration test has been added to verify the functionality.
See gh-35102
Signed-off-by: Daniil Razorenov <daniltmb@gmail.com>
The name is a bit long, but it is necessary to indicate it's a handler
for a deprecation version, and the decision is based on the version,
not an individual endpoint.
See gh-35049
JUnit 5.13 introduced support for Discovery Issues which typically
indicate configuration errors in tests that may result in unexpected
behavior.
Furthermore, discovery issues that are currently reported at INFO level
may later be reported at WARNING or ERROR level -- for example, in
JUnit 6.
In order to ensure that our test suite does not suffer from such
potential errors, this commit sets the
junit.platform.discovery.issue.severity.critical JVM system property to
INFO (instead of leaving it with the default ERROR configuration).
Doing so aligns with our build configuration which fails the build for
selected warnings in Java source code and Javadoc.
If we later determine that INFO causes unnecessary issues for us, we
can switch to WARNING.
This commit also removes two "intentionally invalid" test cases from
AutowiredConfigurationErrorsIntegrationTests, since those test cases
are now reported as invalid as of JUnit 5.13.
Closes gh-35107
API version resolution and parsing is already applied as long as
an ApiVersionStrategy is configured and irrespective of whether
a given RequestMapping has a version or not.
RequestMappingHandlerMapping also needs to be aware of the API version
in order to apply deprecated version handling. So it is better to
resolve, parse, and validate the version in the beginning of
handler mapping rather than in the first call to any
VersionRequestCondition.
Closes gh-35049
The single constructor now supports all combinations of having a version
attribute set or not, and ApiVersionStrategy, configured or not.
In effective, ensure the configured ApiVersionStrategy is passed even
when the RequestMapping version attribute is not set.
See gh-35082
Kotlin 2.2 is the new baseline for Spring Framework 7.0.
-Xannotation-default-target=param-property is specified to avoid
warnings when compiling tests or documentation snippets. It is
expected to become the default behavior in an upcoming version
of Kotlin, see https://youtrack.jetbrains.com/issue/KT-73255 for
more details.
Closes gh-34453
After further consideration, we have decided to remove the recently
introduced MockSslInfo in favor of introducing the following static
factory methods directly in the SslInfo interface.
- SslInfo.from(String sessionId)
- SslInfo from(String sessionId, X509Certificate... peerCertificates)
See gh-35042
See gh-35078
Prior to this commit, there was no easy way to configure an SslInfo
instance for use with WebTestClient.
To address that, this commit introduces a new sslInfo(SslInfo) method
in WebTestClient.MockServerSpec, which can be used as follows.
var client = WebTestClient.bindToApplicationContext(context)
.sslInfo(new MockSslInfo("mock ID"))
// ...
.build();
Closes gh-35042
Prior to this commit, the sslInfo() method in MockServerHttpRequest's
BaseBuilder returned void, which prevented it from being used with the
intended fluent Builder pattern.
This commit changes the return type to the builder (B) for proper method
chaining.
Closes gh-35075
Document that HandlerMethod.toString() is used in log and error messages,
and that the returned description should typically include the method
signature of the underlying handler method for clarity and debugging.
Closes gh-35055
Signed-off-by: WonYong Hwang <111210881+wonyongg@users.noreply.github.com>
Co-authored-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>
This commit fixes a regression introduced in gh-34971 where GET and
DELETE requests would not allow request bodies anymore for
`JdkClientHttpRequest`.
We are now using `builder.GET()` and `builder.DELETE()` methods only if
the provided body is null.
Fixes gh-35068
Historically, we have used `<introduction year>-<modification year>` as
the pattern for copyright headers.
For example: `Copyright 2002-2025 the original author or authors.`
However, we have been encouraged to use `present` as the modification
year.
In light of that, this commit updates the following to enforce the new
pattern.
- The patterns in our SpringHeaderCheck Checkstyle rules
- The `Copyright 2002-${year}` template in org.eclipse.jdt.ui.prefs
- The update_copyright_headers.sh script
See gh-35070
Historically, we have used `<introduction year>-<modification year>` as
the pattern for copyright headers.
For example: `Copyright 2002-2025 the original author or authors.`
However, we have been encouraged to use `present` as the modification
year.
In light of that, this commit updates the following to enforce the new
pattern.
- The patterns in our SpringHeaderCheck Checkstyle rules
- The `Copyright 2002-${year}` template in org.eclipse.jdt.ui.prefs
- The update_copyright_headers.sh script
See gh-35070
Based on RetryTemplate with ExponentialBackOff.
Includes optional jitter support in ExponentialBackOff.
Supports reactive methods through Reactor's RetryBackoffSpec.
Closes gh-34529
Prior to this commit, the `DefaultServerWebExchange` would attempt to
decode request bodies as form-data or multipart of the request
content-type was compatible with the expected media types.
If requests are sent with an invalid wildcard content-type such as "*/*"
or "multipart/*", we should not attempt to decode here.
Fixes gh-34660
Prior to this commit, we had three concrete RetryPolicy implementations.
- MaxRetryAttemptsPolicy
- MaxDurationAttemptsPolicy
- PredicateRetryPolicy
However, there was no way to combine the behavior of those policies.
Furthermore, the PredicateRetryPolicy was practically useless as a
standalone policy, since it did not have a way to end an infinite loop
for a Retryable that continually throws an exception which matches the
predicate.
This commit therefore replaces the current built-in RetryPolicy
implementations with a fluent Builder API and dedicated factory methods
for common use cases.
In addition, this commit also introduces built-in support for
specifying include/exclude lists.
Examples:
new MaxRetryAttemptsPolicy(5) -->
RetryPolicy.withMaxAttempts(5)
new MaxDurationAttemptsPolicy(Duration.ofSeconds(5)) -->
RetryPolicy.withMaxDuration(Duration.ofSeconds(5))
new PredicateRetryPolicy(IOException.class::isInstance) -->
RetryPolicy.builder()
.maxAttempts(3)
.predicate(IOException.class::isInstance)
.build();
The following example demonstrates all supported features of the builder.
RetryPolicy.builder()
.maxAttempts(5)
.maxDuration(Duration.ofMillis(100))
.includes(IOException.class)
.excludes(FileNotFoundException.class)
.predicate(t -> t.getMessage().contains("Unexpected failure"))
.build();
Closes gh-35058
Exposes last exception as cause in RetryException.
Applies first back-off after the initial exception.
Breaks out of retry loop on BackOffExecution.STOP.
Expects null result in Retryable and RetryListener.
Closes gh-35057
Prior to this commit, the `ResourceHttpRequestHandler` would detect
invalid range requests and reply with a 416 response status and the
relevant range header. Because this was triggering an error dispatch,
the error handling would collect error metadata and produce an error
response with the original content-type.
This would most likely fail because the content-type is most likely a
file-related media type which cannot be used for error responses.
This commit resets the response content type in these cases and let the
error handling pick the most sensible media type for the error response.
Fixes gh- 34490
This commit configures a new CheckStyle rule that fails for empty
"catch" blocks, unless the exception is named "ignored" or "expected".
This also fixes the remaining instances missed by the previous commit.
Closes gh-35047
The Spring codebase sometimes ignores exceptions in catch blocks on
purpose. This is often called out by an inline comment.
We should make this more obvious by renaming the exception argument in
the catch block to declare whether the exception is "ignored" or
"expected".
See gh-35047
Signed-off-by: Vincent Potucek <vpotucek@me.com>
[brian.clozel@broadcom.com: rework commit message]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
Prior to this commit, the WebFlux server support would try reading
form-data from the request by:
* first, checking that request content-type is compatible with a
form-data content-type
* then by selecting a message reader that is compatible with the given
request content-type
This approach is flawed because if the content-type provided by the
request is too broad, another message reader could be selected that's
not meant to be used for reading form-data. Typically, a JSON message
reader could be selected and would fail when reading the request.
This problem was previously hidden because message readers would not
support `MultiValueMap` as a target type. Now that some readers support
this type, this can lead to deserialization errors.
This commit now ensures that in all cases, we attempt to read form-data
with a message reader that supports the
"application/x-www-form-urlencoded" media type.
Fixes gh-34660
While we choose our GitHub action to use Bellsoft Liberica, we should
relax that vendor requirement and ensure that contributors can build the
project with any Java 24 distribution.
Closes gh-35043
Use String.replace instead of replaceAll in MetadataEncoder; since Java 9, String.replace
no longer uses a regex, while replaceAll does. The use case here of replacing a single
character does not require a regex.
Closes gh-35025
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Prior to this commit, the "filename" parameter value for the
"Content-Disposition" header would contain non-printable characters,
causing parsing issues for HTTP clients.
This commit ensures that all non-printable characters are encoded.
Fixes gh-35034
Due to lacking support in NullAway for the current arrangement, we are
(perhaps temporarily) changing the signature of the execute() method in
RetryOperations (and thus also in RetryTemplate)...
from: <R extends @Nullable Object> R execute(Retryable<R> retryable);
to: <R> @Nullable R execute(Retryable<? extends @Nullable R> retryable);
Once https://github.com/uber/NullAway/issues/1075 has been resolved, we
will consider switching back to the original signature.
See gh-34716
Previously, when saving a WebSession, the system did not check whether
the session ID already existed. As a result, even if the session being
saved was an update to an existing one, it was incorrectly treated as a
new session, and a "maximum sessions exceeded" error was triggered.
This fix ensures that if a WebSession with the same ID already exists,
it will be updated rather than counted as a new session, thereby
preventing unnecessary session limit violations.
Closes gh-35013
Signed-off-by: Mohammad Saeed Nouri <msnsaeed71@gmail.com>
Thanks to the new Discovery Issue Reporting mechanism introduced in JUnit 5.13, I became
aware of the fact that the @Order annotations in NestedAfterTestClassSqlScriptsTests
were being silently ignored.
To address that, this commit redeclares @TestMethodOrder on @Nested test class.
This commit adds `ProblemDetail` and `ErrorResponse` to the list of
supported return types for `@ExceptionHandler` methods.
Closes gh-34554
Signed-off-by: Vedran Pavic <vedran@vedranpavic.com>
This commit constitutes a first pass over the new core retry support.
- Fix code and Javadoc formatting
- Polish/fix Javadoc
- Fix default FixedBackOff configuration in RetryTemplate
- Consistent logging in RetryTemplate
- Fix listener handling in CompositeRetryListener, allowing addListener()
to work
- Polish tests
- Ensure RetryTemplateTests do not take over 30 seconds to execute
See gh-34716
This commit introduces a minimal core retry feature. It is inspired
by Spring Retry, but redesigned and trimmed to the bare minimum to
cover most cases.
Closes gh-34716
AbstractKotlinSerializationHttpMessageConverter#getSupportedMediaTypes(Class<?>)
currently invokes transitively supports(Class<?>) which always return false
with generic types.
This commit adds an override that just invokes getSupportedMediaTypes().
Closes gh-34992
per https://www.rfc-editor.org/rfc/rfc7232#section-4.1
The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary.
Closes gh-34614
Signed-off-by: James Yuzawa <jtyuzawa@gmail.com>
Prior to this commit, combining the "/*" and "/x/y" path patterns
would result in a `StringIndexOutOfBoundsException`.
This commit fixes this problem and revisits the implementation for
better consistency:
* "/*" + "/x/y" is now "/x/y"
* "/x/*.html" + "/y/file.*" is now rejected because they don't share the
same prefix.
This change also adds the relevant Javadoc to the `PathPattern#combine`
method.
Fixes gh-34986
Replace deprecated JettyHttpHandlerAdapter with JettyCoreHttpHandlerAdapter
Update example to work with Jetty 12+
Add note about the deprecation
See gh-34877
Signed-off-by: kssumin <201566@jnu.ac.kr>
Use HexFormat to perform conversion for unicode-prefixed Strings in CharacterEditor.
Closes gh-34798
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Add optimized DataBufferInputStream overrides for readNBytes, skip, and transferTo; all of them
allocate byte buffers which we can either avoid (in the case of skip) or size more precisely since
the number of remaining bytes is known.
Closes gh-34799
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Prior to this commit, we would use the
`java.net.http.HttpRequest.Builder#method(String, BodyPublisher)` to
create HTTP requests for the JDK HttpClient. This method requires a
non-null body publisher; providing an empty publisher writes a
"Content-Length: 0" header to all requests.
As of Java 19, this behavior changes for `HttpRequest.Builder#GET` and
similar methods, where the body publisher is considered as null and no
"Content-Length" header is written.
This commit aligns with this behavior and favors dedicated HTTP methods
whenever available.`
Closes gh-34971
Prior to this commit, argument index handling in
AutowiredArgumentsCodeGenerator suffered from an off-by-one error when
generating code for an autowired inner class constructor.
Since the startIndex is already properly calculated for an inner class in
InstanceSupplierCodeGenerator.buildGetInstanceMethodForConstructor(...),
there is no need to adjust the argument indexes within
AutowiredArgumentsCodeGenerator.generateCode(...).
Closes gh-34974
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Prior to this commit, the verifyType() method in MessageHeaderAccessor
checked if REPLY_CHANNEL ended with the given header name which does
not make much sense and is inconsistent with the ERROR_CHANNEL check.
This commit therefore checks if the REPLY_CHANNEL is equal to the given
header name, analogous to the ERROR_CHANNEL check.
See gh-34881
Closes gh-34949
Signed-off-by: Mengqi Xu <2663479778@qq.com>
The KotlinDelegate#isNullable invocation is unnecessary since this check
is already done by the Nullness#forField one introduced by
b5d153febf.
See gh-34952
See gh-34261
This commit fixes a regression in PropertySourcesPlaceholderConfigurer
that was introduced in Spring Framework 6.2.7.
Specifically, this commit reinstates automatic String-conversion of
values from PropertySources in the Environment using the
ConversionService configured in the Environment.
See gh-34861
Closes gh-34936
This commit introduces a @Disabled "regression test" which demonstrates
that PropertySourcesPlaceholderConfigurer uses the ConversionService
from the Environment.
See gh-34936
Since setProperty(String, Object) and withProperty(String, Object)
methods were introduced in MockEnvironment in 6.2.8, this commit removes
the obsolete variants with (String, String) signatures.
See gh-34947
Closes gh-34948
The setProperty() and withProperty() methods in MockEnvironment were
originally introduced with (String, String) signatures; however, they
should have always had (String, Object) signatures in order to comply
with the MockPropertySource and PropertySource APIs.
To address that, this commit changes the signatures of these methods so
that they only accept Object values for properties.
NOTE: this commit only affects the internal MockEnvironment used as a
test fixture. This commit does not affect the official, public
MockEnvironment implementation in spring-test.
See gh-34947
See gh-34948
The setProperty() and withProperty() methods in MockEnvironment were
originally introduced with (String, String) signatures; however, they
should have always had (String, Object) signatures in order to comply
with the MockPropertySource and PropertySource APIs.
To address that, this commit introduces variants of these methods that
accept Object values for properties.
Closes gh-34947
This commit declares nullability @Contract annotations for quote() and
getFilename() in StringUtils.
Closes gh-34896
Signed-off-by: Stéphane Nicoll <stephane.nicoll@broadcom.com>
Prior to this commit, a BeanDefinitionReader registered via
@ImportResource was required to be public and have a public
constructor that accepts a single BeanDefinitionRegistry. However, the
public visibility requirements are not necessary, and the requirements
for the constructor's formal parameter list is not documented.
To address those issues, this commit removes the public visibility
restrictions and documents that a BeanDefinitionReader registered via
@ImportResource must declare a constructor that accepts a single
BeanDefinitionRegistry.
In addition, this commit includes the cause of the instantiation
failure in case the registered BeanDefinitionReader cannot be
instantiated.
Closes gh-34928
Prior to this commit, the JAXB message converters would only rely on the
encoding declaration inside the XML document for reading the document.
This would then use the default UTF-8 encoding, even if the HTTP message
has the `"application/xml;charset=iso-8859-1"` Content-Type.
This commit ensures that both `Jaxb2CollectionHttpMessageConverter` and
`Jaxb2RootElementHttpMessageConverter` use the encoding declared in the
HTTP Content-Type, if present.
Fixes gh-34745
BeanDefinitionDsl is allowing to create a bean from a callable
reference with its parameters autowired by type,
BeanRegistrarDsl should allow that too. For example:
class SampleBeanRegistrar : BeanRegistrarDsl({
registerBean<MyRepository>()
registerBean(::myRouter)
})
fun myRouter(myRepository: MyRepository) = router {
...
}
Closes gh-34922
After the bootstrap phase (and with spring.locking.strict=true during the bootstrap phase), getSingletonFactoryBeanForTypeCheck always locks. In a background bootstrap thread, it never locks. Otherwise, it tries locking and explicitly resolves the bean class for subsequent type-based resolution (even for a component-scanned class) when it fails to acquire the lock. Furthermore, getObjectFromFactoryBean follows the same locking algorithm for post-processing.
Closes gh-34902
- Improve Javadoc.
- Suppress warnings for "removal".
- Update copyright headers.
- Migrate several tests from:
- MappingJackson2MessageConverter to JacksonJsonMessageConverter
- Jackson2JsonEncoder to JacksonJsonEncoder
- Jackson2JsonDecoder to JacksonJsonDecoder
- Jackson2SmileEncoder to JacksonSmileEncoder
- Jackson2ObjectMapperBuilder to JsonMapper and XmlMapper
- MappingJackson2JsonView to JacksonJsonView
- MappingJackson2HttpMessageConverter to JacksonJsonHttpMessageConverter
- MappingJackson2XmlHttpMessageConverter to JacksonXmlHttpMessageConverter
NonClosingInputStream extends FilterInputStream, which does not forward some
newer InputStream methods such as transferTo and readAllBytes. Specific InputStream
implementations may have more optimized methods (e.g., FileInputStream).
Closes gh-34893
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
This commit introduces RequestBodyAdvice#determineReadHints and
ResponseBodyAdvice#determineWriteHints in order to be able to support
SmartHttpMessageConverter hints, as well as related `@JsonView`
support.
See gh-33798
This commit introduces Jackson 3 based variants of the following
Jackson 2 classes (and related dependent classes).
MappingJackson2JsonView -> JacksonJsonView
MappingJackson2XmlView-> JacksonXmlView
See gh-33798
This commit introduces Jackson 3 SmartHttpMessageConverter based
variants of the following Jackson 2 classes (and related dependent classes).
org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter ->
org.springframework.http.converter.AbstractJacksonHttpMessageConverter
MappingJackson2HttpMessageConverter -> JacksonJsonHttpMessageConverter
MappingJackson2SmileHttpMessageConverter -> JacksonSmileHttpMessageConverter
MappingJackson2CborHttpMessageConverter -> JacksonCborHttpMessageConverter
MappingJackson2XmlHttpMessageConverter -> JacksonXmlHttpMessageConverter
MappingJackson2YamlHttpMessageConverter -> JacksonYamlHttpMessageConverter
They use hints instead of MappingJacksonValue and MappingJacksonInputMessage
to support `@JsonView` and FilterProvider.
Jackson 3 support is configured if found in the classpath otherwise
fallback to Jackson 2.
JacksonHandlerInstantiator needs to be enabled explicitly if needed.
See gh-33798
This commit introduces a
org.springframework.http.support.JacksonHandlerInstantiator Jackson 3
variant of org.springframework.http.converter.json.SpringHandlerInstantiator
Jackson 2 class.
See gh-33798
This commit introduces Jackson 3 variants of the following Jackson 2
classes (and related dependent classes).
org.springframework.http.codec.json.Jackson2CodecSupport ->
org.springframework.http.codec.JacksonCodecSupport
org.springframework.http.codec.json.Jackson2Tokenizer ->
org.springframework.http.codec.JacksonTokenizer
org.springframework.http.codec.json.Jackson2SmileDecoder ->
org.springframework.http.codec.smile.JacksonSmileDecoder
org.springframework.http.codec.json.Jackson2SmileEncoder ->
org.springframework.http.codec.smile.JacksonSmileEncoder
Jackson2CborDecoder -> JacksonCborDecoder
Jackson2CborEncoder -> JacksonCborEncoder
Jackson2JsonDecoder -> JacksonJsonDecoder
Jackson2JsonEncoder -> JacksonJsonEncoder
Jackson 3 support is configured if found in the classpath otherwise
fallback to Jackson 2.
See gh-33798
Spring Framework 6.2 introduced support for an escape character for
property placeholders (by default '\'). However, as of Spring Framework
6.2.6, there was no way to either escape the escape character or disable
escape character support.
For example, given a `username` property configured with the value of
`Jane.Smith` and a `DOMAIN\${username}` configuration string, property
placeholder replacement used to result in `DOMAIN\Jane.Smith` prior to
6.2 but now results in `DOMAIN${username}`. Similarly, an attempt to
escape the escape character via `DOMAIN\\${username}` results in
`DOMAIN\${username}`.
In theory, one should be able to disable use of an escape character
altogether, and that is currently possible by invoking
setEscapeCharacter(null) on AbstractPropertyResolver and
PlaceholderConfigurerSupport (the superclass of
PropertySourcesPlaceholderConfigurer).
However, in reality, there are two hurdles.
- As of 6.2.6, an invocation of setEscapeCharacter(null) on a
PropertySourcesPlaceholderConfigurer applied to its internal
top-level PropertySourcesPropertyResolver but not to any nested
PropertySourcesPropertyResolver, which means that the `null` escape
character could not be effectively applied.
- Users may not have an easy way to explicitly set the escape character
to `null` for a PropertyResolver or
PropertySourcesPlaceholderConfigurer. For example, Spring Boot
auto-configures a PropertySourcesPlaceholderConfigurer with the
default escape character enabled.
This first issue above has recently been addressed by gh-34861.
This commit therefore addresses the second issue as follows.
- To allow developers to easily revert to the pre-6.2 behavior without
changes to code or configuration strings, this commit introduces a
`spring.placeholder.escapeCharacter.default` property for use with
SpringProperties which globally sets the default escape character that
is automatically configured in AbstractPropertyResolver and
PlaceholderConfigurerSupport.
- Setting the property to an empty string sets the default escape
character to `null`, effectively disabling the default support for
escape characters.
spring.placeholder.escapeCharacter.default =
- Setting the property to any other character sets the default escape
character to that specific character.
spring.placeholder.escapeCharacter.default = ~
- Setting the property to a string containing more than one character
results in an exception.
- Developers are still able to configure an explicit escape character
in AbstractPropertyResolver and PlaceholderConfigurerSupport if they
choose to do so.
- Third-party components that wish to rely on the same feature can
invoke AbstractPropertyResolver.getDefaultEscapeCharacter() to obtain
the globally configured default escape character.
See gh-9628
See gh-34315
See gh-34861
Closes gh-34865
Prior to this commit, the new `ClassFileAnnotationMetadata` would fail
when reading `Class<T>` annotation attributes when values are primitive
types.
This commit uses `java.lang.constant.ClassDesc` to better parse type
descriptors from the bytecode.
Fixes gh-24882
PropertyPlaceholderConfigurer and PreferencesPlaceholderConfigurer have
been officially deprecated since Spring Framework 5.2.
Since we no longer expect applications to depend on these outdated
mechanisms, this commit deprecates these classes "for removal" in
Spring Framework 8.0.
Closes gh-34880
This commit overrides containsProperty() in
FallbackEnvironmentPropertySource for consistency with the
implementation of ConfigurableEnvironmentPropertySource.
See gh-34861
Although it's unlikely that the implementation of getPropertySources()
in a ConfigurableEnvironment would be overridden to return a different
MutablePropertySources instance than the one that the
ConfigurableEnvironment typically acts on, it is in fact possible.
In light of that possibility, this commit refactors
ConfigurableEnvironmentPropertySource so that it always obtains a fresh
PropertySources reference.
See gh-34861
Commit 3295289e17 fixed a number issues with placeholder resolution in
PropertySourcesPlaceholderConfigurer. However, in doing so, it replaced
a raw PropertySource with a CompositePropertySource which implements
EnumerablePropertySource.
Consequently, all property sources registered in the Environment must
now implement EnumerablePropertySource (which is not an actual
requirement). Otherwise, invocations of getPropertyNames() on the
CompositePropertySource result in an IllegalStateException, and that is
a breaking change which resulted in numerous build failures within the
Spring portfolio.
To address that regression, this commit introduces a private
ConfigurableEnvironmentPropertySource in
PropertySourcesPlaceholderConfigurer which is a "raw" PropertySource
that delegates directly to the PropertySources in a
ConfigurableEnvironment.
This commit also extracts the raw PropertySource for direct Environment
delegation into a new FallbackEnvironmentPropertySource.
See gh-17385
Closes gh-34861
Currently, the placeholder resolution algorithm in
PropertySourcesPlaceholderConfigurer fails in several scenarios, and
the root cause for this category of failures has actually existed since
PropertySourcesPlaceholderConfigurer was introduced in Spring Framework
3.1.
Specifically, PropertySourcesPlaceholderConfigurer creates its own
PropertySourcesPropertyResolver that indirectly delegates to another
"nested" PropertySourcesPropertyResolver to interact with
PropertySources from the Environment, which results in double
placeholder parsing and resolution attempts, and that behavior leads to
a whole category of bugs.
For example, #27947 was addressed in Spring Framework 5.3.16, and due
to #34315 and #34326 we have recently realized that additional bugs
exist with placeholder resolution: nested placeholder resolution can
fail when escape characters are used, and it is currently impossible
to disable the escape character support for nested resolution.
To address this category of bugs, we no longer indirectly use or
directly create a "nested" PropertySourcesPropertyResolver in
PropertySourcesPlaceholderConfigurer. Instead, properties from property
sources from the Environment are now accessed directly without
duplicate/nested placeholder resolution.
See gh-27947
See gh-34326
See gh-34862
Closes gh-34861
Update `ClassFileClassMetadata` so that member classes only include
immediate children. This aligns with the other `ClassMetadata`
implementations.
Closes gh-34869
Update `ClassFileClassMetadata` to align the behavior of
`getSuperClassName()` with other readers in that it returns
`null` for `package-info` classes.
See gh-34869
The last assertion of the new test method currently fails since "foo"
is only bound once.
java.lang.AssertionError:
Expected size: 2 but was: 1 in:
{0="foo"}
See gh-34768
This commit introduces a new constructor for CompositePropertySource
that accepts a `String name` and an Iterable<PropertySource<?>>, which
allows a CompositePropertySource to be constructed from existing
property sources, such as an instance of MutablePropertySources.
Closes gh-34862
As of gh-33806, the HttpComponents client request factory is forward
compatible with the 5.4+ versions of that library for configuring HTTP
request configuration.
This change would not tkae into account configuration set at the Spring
level because it would consider the default `RequestConfig` instance as
a custom one. This commit ensures that Spring sets its own configuration
if no custom configuration was set for all supported HttpComponents
generations.
Fixes gh-34851
Prior to this commit, bean overrides (such as @MockitoBean, etc.) were
discovered multiple times if they were declared:
- at the type-level on an interface that is implemented at more than
one level in the type hierarchy, the enclosing class hierarchy, or a
combination of the type and enclosing class hierarchies.
or
- on a field declared in a class which can be reached multiple times
while traversing the type and enclosing class hierarchies in
scenarios such as the following: the class (X) in which the field is
declared is a supertype of an enclosing type of the test class, and X
is also an enclosing type of a supertype of the test class.
Such scenarios resulted in an IllegalStateException stating that a
duplicate BeanOverrideHandler was discovered.
To address that, this commit revises the search algorithm in
BeanOverrideHandler so that all types (superclasses, enclosing classes,
and implemented interfaces) are only visited once while traversing the
type and enclosing class hierarchies in search of bean override
handlers.
See gh-33925
See gh-34324
Closes gh-34844
Update interface client code to replace `GroupsMetadata.loadClass` calls
with `ClassUtils.resolveClassName` passing in the bean class loader.
Since the bean class loader in injected after construction, some minor
refactoring has been applied to `HttpServiceProxyRegistryFactoryBean`.
The class now stores `GroupsMetadata` and only loads the types in
in `afterPropertiesSet`.
The `HttpServiceProxyFactory` class has also been updated to ensure
that the proxy is created using the class loader of the service
type, rather than the thread context class loader.
Fixes gh-34846
To ensure that failures in javadoc tasks do not result in documentation
silently not being generated/published, this commit sets
`failOnError = true` for all javadoc tasks.
See gh-27497
See gh-34774
Closes gh-34837
In commit 49ef150c5d, I stated that the common javadoc task used by all
spring-* modules would be addressed in a separate commit. However,
after further investigation I determined that the spring-test Javadoc
JAR was published successfully, including links to JUnit 5 Javadoc
(which was not previously the case).
https://repo1.maven.org/maven2/org/springframework/spring-test/7.0.0-M4/spring-test-7.0.0-M4-javadoc.jar
This commit therefore only adds a note in JavaConventions to remind us
that the aggregated Javadoc toolchain configuration needs to stay in
sync with the configuration in JavaConventions.
See gh-27497
Closes gh-34774
In 49e5c84928 I unfortunately overlooked
several JUnit 4 based tests in the `junit4` package that should be
migrated to JUnit Jupiter.
This commit address those remaining test classes.
See gh-23451
See gh-34794
Closes gh-34813
This commit revises the implementation of TestConventions so that
existing JUnit Platform options from a pre-configured `test` task are
copied instead of overridden.
Closes gh-34827
In commit 05ebca8677, the `public` modifier was removed from the
SpringAtInjectTckTests class, which prevents it from being run as a
JUnit 3 test class.
To address that, this commit adds the missing `public` modifier as well
as a a code comment to help prevent this from happening again.
In addition, this commit updates spring-context.gradle to ensure that
the JUnit Vintage test engine is always applied. However, that Gradle
configuration is unfortunately ignored due to how our TestConventions
class has been implemented. Thus, that issue will have to be addressed
separately.
Closes gh-34800
In Spring Framework 5.2, we migrated most of the test suite from JUnit
4 to JUnit Jupiter; however, prior to this commit, several tests in the
spring-test module were still based on JUnit 4 unnecessarily.
Since we are now planning to deprecate our JUnit 4 support in 7.0, this
commit migrates our remaining JUnit 4 based tests to JUnit Jupiter
whenever feasible. In the process, test classes that previously resided
under the "junit4" package have been moved to new packages directly
under the "org.springframework.text.context" package, and several
classes have been renamed for greater clarity of purpose.
Consequently, the only remaining tests based on JUnit 4 are those tests
that are required to run with JUnit 4 in order to test our JUnit 4
support.
This commit also greatly simplifies exclusions for Checkstyle rules
pertaining to JUnit usage.
See gh-23451
See gh-34794
Closes gh-34813
This commit makes AbstractJackson2HttpMessageConverter#getObjectMappersForType
return value non nullable as an empty map is returned in case of no
registrations.
Closes gh-34811
Changes made in conjunction with #27497 now require that we generate
Javadoc with JDK 18 or higher in order to make use of the
"--link-modularity-mismatch" flag for the javadoc executable.
This commit sets the toolchain for the javadoc task in the
framework-api module to use JDK 24 for generating Javadoc.
The common javadoc task used by all spring-* modules will be addressed
in a separate commit.
See gh-27497
See gh-34774
We now invoke the javadoc tool with "--link-modularity-mismatch info"
in order not to fail the build when encountering warnings such as the
following.
> The code being documented uses packages in the unnamed module, but the
> packages defined in https://junit.org/junit5/docs/5.12.2/api/ are in
> named modules.
Closes gh-27497
This commit adds AOT support for restoring the state of the
HttpServiceProxyRegistry. This generates code for the groupsMetadata
as well as for the creation of the client proxies.
Closes gh-34750
This commit makes BeanDefinitionPropertyValueCodeGeneratorDelegates
public and offer a convenience method to create a ValueCodeGenerator
that works will all core delegates.
Closes gh-34761
This commit updates framework-platform to manage the dependency of JBoss
Logging. This leads to problem previously as Hibernate Validator
requires a recent version of JBoss Logging that other dependencies
haven't upgraded to yet.
Closes gh-34749
Specifically, the documentation update reflects that:
- Initially, it was mentioned that only the `BeanFactoryAware`
interface is ignored by default.
- The updated documentation now correctly states that `BeanNameAware`,
`BeanFactoryAware`, and `BeanClassLoaderAware` interfaces are all
ignored by default.
This change ensures a more accurate representation of the default
behavior regarding which dependency interfaces are automatically
ignored during autowiring in the context of Spring's bean factory
mechanism.
Closes gh-34747
Signed-off-by: lituizi <2811328244@qq.com>
Includes spring.locking.strict revision to differentiate between true, false, not set.
Includes checkFlag accessor on SpringProperties, also used in StatementCreatorUtils.
Closes gh-34729
See gh-34303
This commit provides first-class support for Bean Overrides
(@MockitoBean, @MockitoSpyBean, @TestBean, etc.) with
@ContextHierarchy.
Specifically, bean overrides can now specify which ApplicationContext
they target within the context hierarchy by configuring the
`contextName` attribute in the annotation. The `contextName` must match
a corresponding `name` configured via @ContextConfiguration.
For example, the following test class configures the name of the second
hierarchy level to be "child" and simultaneously specifies that the
ExampleService should be wrapped in a Mockito spy in the context named
"child". Consequently, Spring will only attempt to create the spy in
the "child" context and will not attempt to create the spy in the
parent context.
@ExtendWith(SpringExtension.class)
@ContextHierarchy({
@ContextConfiguration(classes = Config1.class),
@ContextConfiguration(classes = Config2.class, name = "child")
})
class MockitoSpyBeanContextHierarchyTests {
@MockitoSpyBean(contextName = "child")
ExampleService service;
// ...
}
See gh-33293
See gh-34597
See gh-34726
Closes gh-34723
Signed-off-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>
For bean override support (@MockitoBean, @TestBean, etc.), the logic
for field injection previously resided in the BeanOverrideRegistry
which resulted in a strange mixture of concerns.
To address that, this commit moves the field injection logic to the
BeanOverrideTestExecutionListener, and the BeanOverrideRegistry now
serves a single role, namely the role of a registry.
Closes gh-34726
This commit makes CORS preflight requests handling more flexible
by just skipping setting CORS response headers when no
configuration is defined instead of rejecting them.
That will have the same effect on user agent side (the preflight
request will be considered as not authorized and the actual
request not performed) but is more flexible and more efficient.
Closes gh-31839
- ClassUtils.isAssignable(): Avoid Map lookup when the type is not a
primitive.
- AnnotationsScanner: Perform low cost array length check before String
comparisons.
- BeanFactoryUtils: Use char comparison instead of String comparison.
The bean factory prefix is '&', so we can use a char comparison
instead of more heavyweight String.startsWith("&").
- AbstractBeanFactory.getMergedBeanDefinition(): Perform the low cost
check first. Map lookup, while cheap, is still more expensive than
instanceof.
Closes gh-34717
Signed-off-by: Olivier Bourgain <olivierbourgain02@gmail.com>
This commit evolves the CDS documentation to a JVM AOT cache
one for Java 24+, while still documenting how to use CDS for
Java 17 to Java 23.
Closes gh-34700
This commit adds another optimization mainly for the use case where
there is no encoded sequence, and updates the Javadoc of both
StringUtils#uriDecode and UriUtils#decode to match the implementation.
Closes gh-34673
Refine the StringUtils#uriDecode method in the following ways:
- Use a StringBuilder instead of ByteArrayOutputStream, and only decode
%-encoded sequences.
- Use HexFormat.fromHexDigits to decode hex sequences.
- Decode to a byte array that is only allocated if encoded sequences are
encountered.
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
See gh-34673
Prior to this commit, the `DefaultWebClient` observability
instrumentation would create the observation context before the reactive
pipeline is fully materialized. In case of errors and retries (with the
`retry(long)` operator), the observation context would be reused for
separate observations, which is incorrect.
This commit ensures that a new observation context is created for each
subscription.
Fixes gh-34671
This commit is a follow-up to gh-34592. It introduces
recursive boxing of Kotlin nested value classes in CoroutinesUtils.
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
Closes gh-34682
Historically, @Configuration classes that did not declare @Bean
methods were allowed to be abstract. However, the changes made in
76a6b9ea79 introduced a regression that prevents such classes from
being abstract, resulting in a BeanInstantiationException. This change
in behavior is caused by the fact that such a @Configuration class is
no longer replaced by a concrete subclass created dynamically by CGLIB.
This commit restores support for abstract @Configuration classes
without @Bean methods by modifying the "no enhancement required" check
in ConfigurationClassParser.
See gh-34486
Closes gh-34663
This commit fixes a minor typo in the "Java Bean Validation - Customizing
Validation Errors" section of the reference manual.
Closes gh-34686
Signed-off-by: Tobias Hänel <contact@tobias-haenel.de>
To help with AOT support, update AbstractHttpServiceRegistrar to store
HTTP Service types by name, and avoid loading classes during the bean
definition registration phase.
See gh-33992
This commit fixes a minor typo in the "Java Bean Validation - Customizing
Validation Errors" section of the reference manual.
Closes gh-34686
Signed-off-by: Tobias Hänel <contact@tobias-haenel.de>
We have had an ObjectToOptionalConverter since Spring Framework 4.1;
however, prior to this commit we did not have a standard Converter for
the inverse (Optional to Object).
To address that, this commit introduces an OptionalToObjectConverter
that unwraps an Optional, using the ConversionService to convert the
object contained in the Optional (potentially null) to the target type.
This allows for conversions such as the following.
- Optional.empty() -> null
- Optional.of(42) with Integer target -> 42
- Optional.of(42) with String target -> "42"
- Optional.of(42) with Optional<String> target -> Optional.of("42")
The OptionalToObjectConverter is also registered by default in
DefaultConversionService, alongside the existing
ObjectToOptionalConverter.
See gh-20433
Closes gh-34544
Prior to this commit, the Test Bean Override feature provided support
for overriding beans based on qualifier annotations in several
scenarios; however, qualifier annotations got lost if they were
declared on the return type of the @Bean method for the bean being
overridden and the @BeanOverride (such as @MockitoBean) was based on
a supertype of that return type.
To address that, this commit sets the @BeanOverride field as the
"qualified element" in the RootBeanDefinition to ensure that qualifier
annotations are available for subsequent autowiring candidate
resolution.
Closes gh-34646
This commit updates the tests of property values code generated to
invoke the generated code from a `static` context. This ensures that
the test fails if that's not the case.
This commit also updated LinkedHashMap handling that did suffer from
that problem.
Closes gh-34659
This commit introduces a new ResponseSpec.awaitEntityOrNull() extension
function to replace ResponseSpec.toEntity(...).awaitFirstOrNull() and
pass the CoroutineContext to the CoExchangeFilterFunction.
CoroutineContext propagation is implemented via ReactorContext and
ClientRequest attribute.
Closes gh-34555
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
Prior to this commit, Spring Framework would use its own ASM fork to
read class/method/annotation metadata from bytecode. This is typically
used in configuration class parsing to build bean definitions without
actually loading classes at runtime at that step.
This commit adds support for a new metadata reading implementation that
uses the ClassFile API available as of Java 24. For now, this is turned
on by default for Java 24+.
Closes gh-33616
Now that we are using JDK 18+ (currently JDK 24 -- see JavaConventions
in buildSrc for details), we can reinstate links to JUnit 5 Javadoc APIs.
Closes gh-27497
This commit updates the Javadoc in various places to reflect the fact
that support for convention-based annotation attribute overrides has
been removed.
See gh-28761
Historically, the Spring Framework first had support for repeatable
annotations based on convention and later added explicit support for
Java 8's @Repeatable facility. Consequently, the support for both
types of repeatable annotations has grown a bit intertwined over the
years. However, modern Java applications typically make use of
@Repeatable, and convention-based repeatable annotations have become
more of a niche.
The RepeatableContainers API supports both types of repeatable
annotations with @Repeatable support being the default. However,
RepeatableContainers.of() makes it very easy to enable support for
convention-based repeatable annotations while accidentally disabling
support for @Repeatable, which can lead to subtle bugs – for example,
if convention-based annotations are combined with @Repeatable
annotations. In addition, it is not readily clear how to combine
@Repeatable support with convention-based repeatable annotations.
In light of the above, this commit revises the RepeatableContainers API
to better guide developers to use @Repeatable support for almost all
use cases while still supporting convention-based repeatable
annotations for special use cases.
Specifically:
- RepeatableContainers.of() is now deprecated in favor of the new
RepeatableContainers.explicitRepeatable() method.
- RepeatableContainers.and() is now deprecated in favor of the new
RepeatableContainers.plus() method which declares the repeatable and
container arguments in the same order as the rest of Spring
Framework's repeated annotation APIs.
For example, instead of the following confusing mixture of
repeatable/container and container/repeatable:
RepeatableContainers.of(A.class, A.Container.class)
.and(B.Container.class, B.class)
Developers are now be able to use:
RepeatableContainers.explicitRepeatable(A.class, A.Container.class)
.plus(B.class, B.Container.class)
This commit also overhauls the Javadoc for RepeatableContainers and
explicitly points out that the following is the recommended approach to
support convention-based repeatable annotations while retaining support
for @Repeatable.
RepeatableContainers.standardRepeatables()
.plus(MyRepeatable1.class, MyContainer1.class)
.plus(MyRepeatable2.class, MyContainer2.class)
See gh-20279
Closes gh-34637
Before RfcUriParser we expected opaque URI's to not have ":/"
after the scheme while the new parser expect opaque URI's to
not have a slash anywhere after the scheme. This commit
restores the previous behavior.
Closes gh-34588
This commit extracts AnnotatedElementAdapter from TypeDescriptor and
introduces it as a public, top-level type in the
org.springframework.core.annotation package, and
AnnotatedElementUtils.forAnnotations() now returns an instance of
AnnotatedElementAdapter instead of AnnotatedElementForAnnotations which
has been removed.
In addition, this commit adds missing Javadoc for
AnnotatedElementAdapter and refines some of the implementation.
Closes gh-34628
This commit replaces use of the deprecated Gradle `task` method with
the new `tasks.register` method.
Closes gh-34617
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
This commit removes the BDDMockito Checkstyle rule, since it did not
actually enforce the use of BDDMockito.
This commit also updates static imports to use Mockito instead of
BDDMockito where appropriate (automated via the Eclipse IDE Organize
Imports clean-up task).
Closes gh-34616
Unfortunately, it is not possible to raise the byte code level beyond
Java 1.8 for classes generated using CGLIB due to the fact that CGLIB
generates STATICHOOK methods which set static final fields outside the
initializer method <clinit> (i.e., a static initialization block).
Attempting to raise the level to Java 17 (or even Java 9) results in
exceptions like the following.
Caused by: java.lang.IllegalAccessError: Update to static final field
org.example.MyBean$$SpringCGLIB$$0.CGLIB$THREAD_CALLBACKS attempted from
a different method (CGLIB$STATICHOOK1) than the initializer method <clinit>
at org.example.MyBean$$SpringCGLIB$$0.CGLIB$STATICHOOK1(<generated>)
at org.example.MyBean$$SpringCGLIB$$0.<clinit>(<generated>)
This commit therefore introduces inline comments pointing out why we
stay with Java 1.8 byte code level with CGLIB.
See gh-34602
FormHttpMessageConverter could throw a more specific
HttpMessageNotReadableException instead of an IllegalArgumentException
when the http form data is invalid.
See gh-34594
Signed-off-by: Russell Bolles <rbolles@netflix.com>
This commit removes the use of RepeatableContainers.of() in
AnnotationJmxAttributeSource since that is unnecessary when using the
MergedAnnotations API with @Repeatable annotations such as
@ManagedOperationParameter and @ManagedNotification.
Closes gh-34606
This commit introduces null-safe support for java.util.Optional in the
following SpEL operators:
- PropertyOrFieldReference
- MethodReference
- Indexer
- Projection
- Selection
- Elvis
Specifically, when a null-safe operator is applied to an empty
`Optional`, it will be treated as if the `Optional` were `null`, and
the subsequent operation will evaluate to `null`. However, if a
null-safe operator is applied to a non-empty `Optional`, the subsequent
operation will be applied to the object contained in the `Optional`,
thereby effectively unwrapping the `Optional`.
For example, if `user` is of type `Optional<User>`, the expression
`user?.name` will evaluate to `null` if `user` is either `null` or an
empty `Optional` and will otherwise evaluate to the `name` of the
`user`, effectively `user.get().getName()` for property access.
Note, however, that invocations of methods defined in the `Optional`
API are still supported on an empty `Optional`. For example, if `name`
is of type `Optional<String>`, the expression `name?.orElse('Unknown')`
will evaluate to "Unknown" if `name` is an empty `Optional` and will
otherwise evaluate to the `String` contained in the `Optional` if
`name` is a non-empty `Optional`, effectively `name.get()`.
Closes gh-20433
This commit introduces a new BeanRegistrarDsl that supersedes
BeanDefinitionDsl which is now deprecated.
See BeanRegistrarDslConfigurationTests for a concrete example.
See gh-18353
This commit introduces a new BeanRegistrar interface that can be
implemented to register beans programmatically in a concise and
flexible way.
Those bean registrar implementations are typically imported with
an `@Import` annotation on `@Configuration` classes.
See BeanRegistrarConfigurationTests for a concrete example.
See gh-18353
This commit completely removes all support for convention-based
annotation attribute overrides in Spring's annotation utilities and the
MergedAnnotations infrastructure.
Composed annotations must now use @AliasFor to declare explicit
overrides for attributes in meta-annotations.
See gh-28760
Closes gh-28761
This commit revisit the build configuration to enforce the following:
* A single Java toolchain is used consistently with a recent Java
version (here, Java 23) and language level
* the main source is compiled with the Java 17 "-release" target
* Multi-Release classes are compiled with their respective "-release"
target. For now, only "spring-core" ships Java 21 variants.
Closes gh-34507
Prior to this commit, `SimpleKey` would be used in Spring Framework's
caching support and its `hashCode` value would be used to efficiently
store this key in data structures.
While the current hashcode strategy works, the resulting values don't
spread well enough when input keys are sequential (which is often the
case). This can have negative performance impacts, depending on the
data structures used by the cache implementation.
This commit improves the `hashCode` function with a mixer to better
spread the hash values. This is using the mixer function from the
MurMur3 hash algorithm.
Closes gh-34483
This commit revisits the behavior of our `MockHttpServletResponse`
implementation with the javadoc clarifications applied in Servlet 6.1.
Prior to this change, adding or setting an HTTP response header with a
`null` name or value would not have the expected behavior:
* a `null` name should have no effect instead of throwing exceptions
* a `null` value when setting a header effectively removes the entry
from the response headers
Also, this commit ensures that `IllegalStateException` are thrown if
`getWriter` is called after a previous `getOutputStream` (and vice
versa).
Closes gh-34467
This commit introduces open polymorphism support with Kotlin
Serialization in HTTP converters and codecs as a follow-up of gh-34410
which considers Kotlin Serialization as a Jackson/Gson/Jsonb equivalent
(it is not anymore configured before Jackson).
Closes gh-34433
In addition to the wrapping of errors recognized as client disconnected
errors with AsyncRequestNotUsableException, we now wrap any IOException
in the onError callback. The Servlet container would only be aware of
such an exception if it relates to the response.
Closes gh-33832
Prior to this commit, Spring MVC and WebFlux would consider the
"kotlinx.serialization" JSON codecs and converters in addition to other
JSON alternatives like Jackson, Gson and Jsonb.
This would cause issues because while in most cases this library is only
involved if the type is annotated with "@Serializable", this is not true
for Java enums. In this particular case, the codec shadows Jackson and
causes issues.
This commit now considers kotlinx.serialization JSON support as an
alternative to Jackson. Just like Jsonb and GSON, this is only
auto-detected if Jackson is not present.
We received consistent feedback that kotlinx.serialization is popular in
Kotlin libraries and is often a transitive dependency. As a result, we
cannot consider its presence on the classpath as a strong enough signal
to configure it by default.
Closes gh-34410
Prior to this commit, if a custom stereotype annotation was
meta-annotated with @Component and declared a local String `value`
attribute that was explicitly configured (via @AliasFor) as an
override for an attribute other than @Component.value, the local
`value` attribute was still used as a convention-based override for
@Component.value.
Consequently, a local `value` attribute was used as a custom
@Component name, even when that is clearly not the intent.
To address that, this commit revises the logic in
AnnotationBeanNameGenerator so that a `value` attribute which is
explicitly aliased to something other than @Component.value is no
longer used as an explicit @Component name.
See gh-34317
Closes gh-34346
As of gh-33913, `HttpHeaders` does not implement the `MultiValueMap`
contract anymore, so we can take this opportunity to simplify one of the
constructors to not consider that the argument could be an `HttpHeaders`
instance. This case is already covered by the other constructor.
See gh-33913
Prior to this commit, the `HttpHeaders` class would provide constructor
variants where the instances are are backed by the existing headers
collection given as a parameter.
While such constructors are clearly documented and meant for internal
usage, there are cases where developers would like to copy the data from
an existing headers instance without being backed by the same collection
instance and thus, being mutated from some place else.
This commit introduces new factory methods `HttpHeaders.copyOf` for this
purpose. While this name aligns with some of the Java collections
factory methods, in this case the returned instance is not immutable, on
purpose. `HttpHeaders` does not extends `MultiValueMap` anymore and
shouldn't be seen as such.
Closes: gh-34341
Signed-off-by: Bryce J. Fisher <bryce.fisher@gmail.com>
[brian.clozel@broadcom.com: reduce scope and update javadoc]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
The spring-jcl module no longer exists on main, but it still exists on
the 6.2.x branch and previous branches and can cause build failures when
switching between branches.
This commit introduces a Nullness enum with related utility methods
in order to detect if a type usage, a field, a method return type or a
parameter is unspecified, nullable or not null.
JSpecify annotations are fully supported, as well as Kotlin null safety
and `@Nullable` annotations regardless of their package (from Spring,
JSR-305 or Jakarta set of annotations for example).
Closes gh-34261
In ClassUtils.forName(), we originally delegated to
ClassLoader.loadClass(), which does not support loading classes from
binary names for arrays (such as "[[I" for "int[][]" or
"[Ljava.lang.String;" for "String[]"); whereas, Class.forName() does
support binary names for arrays.
However, in Spring Framework 5.1.1 we switched from using
ClassLoader.loadClass() to Class.forName() in ClassUtils.forName() (see
gh-21867), which makes our custom handling of binary names for arrays
in ClassUtils.forName() obsolete.
In light of that, this commit removes our custom binary array name
handling support from ClassUtils.forName().
Closes gh-34291
This commit refines KotlinDetector usages and implementation in order
to remove preliminary KotlinDetector#isKotlinReflectPresent invocations
and to ensure that KotlinDetector methods are implemented safely and
efficiently for such use case.
Closes gh-34275
This commit adds a new custom build Plugin, the `ArchitecturePlugin`.
This plugin is using ArchUnit to enforce several rules in the main
sources of the project:
* All "package-info" should be `@NullMarked`
* Classes should not import forbidden types (like "reactor.core.support.Assert"
* Java Classes should not import "org.jetbrains.annotations.*" annotations
* Classes should not call "toLowerCase"/"toUpperCase" without a Locale
* There should not be any package tangle
Duplicate rules were removed from checkstyle as a result.
Note, these checks only consider the "main" source sets, so test
fixtures and tests are not considered. Repackaged sources like JavaPoet,
CGLib and ASM are also excluded from the analysis.
Closes gh-34276
As of gh-33847, method and field introspection is included by default
when a type is registered for reflection.
Many methods in ReflectionHintsPredicates are now mostly useless as their
default behavior checks for introspection.
This commit deprecates those methods and promotes instead invocation
variants. During the upgrade, developers should replace it for an
`onType` check if only reflection is required. If they were checking for
invocation, they should use the new 'onXInvocation` method.
Closes gh-34239
Code that compiles against the non-deprecated version does not see the
new constructor that has been introduced. As such, there is no way for
them to migrate to it without resorting to reflection.
This commit restores the deprecated constructor so that people can try
the latest version more easily.
Closes gh-34238
In order to be able to fix gh-34140 which requires using at least a
Java 22 compiler, this commit intends to change the configuration of
the Gradle toolchain to use Java 23, while setting the Java release to
Java 17 (or other versions when using MRJARs) when relevant in order to
keep the current Java 17 baseline.
See gh-34220
The bufferingPredicate configured in RestClient.Builder can and should also
be used in the (existing) shouldBuffer protected method in
BufferingClientHttpRequestFactory since the factory is no longer intended
for direct use, and in any case the setting should apply in all cases
including when there are no interceptors.
See gh-33785
This commit deprecates the `PathResource` implementation variant in
favor of `FileSystemResource`. This was already pointing to
`FileSystemResource` as of Spring Framework 5.1 and we now consider this
variant as deprecated.
Closes gh-34206
This commit updates the null-safety documentation to use "nullness"
instead of "nullability" in order to be consistent with the JSpecify
documentation.
See gh-28797
Prior to this commit, an `ClientHttpRequestInterceptor` implementation
could delegate HTTP calls to the next `ClientHttpRequestExecution` only
once. Calling the execution would advance to the next interceptor in the
chain in a mutable fashion for the entire lifetime of the current
exchange.
This commit changes the implementation of `InterceptingClientHttpRequest`
so that a `ClientHttpRequestInterceptor` implementation can call
`ClientHttpRequestExecution#execute` multiple times.
This is especially useful for interceptors in case they want to issue
other HTTP requests without needing another `RestTemplate` or
`RestClient` instance provided out of band.
Closes gh-34169
This change removes the `MultiValueMap` nature of `HttpHeaders`, since
it inherits APIs that do not align well with underlying server
implementations. Notably, methods that allows to iterate over the whole
collection of headers are susceptible to artificially introduced
duplicates when multiple casings are used for a given header, depending
on the underlying implementation.
This change includes a dedicated key set implementation to support
iterator-based removal, and either keeps map method implementations that
are relevant or introduces header-focused methods that have a similar
responsibility (like `hasHeaderValues(String, List)` and
`containsHeaderValue(String, String)`).
In order to nudge users away from using an HttpHeaders as a Map, the
`asSingleValueMap` view is deprecated. In order to offer an escape
hatch to users that do make use of the `MultiValueMap` API, a similar
`asMultiValueMap` view is introduced but is immediately marked as
deprecated.
This change also adds map-like but header-focused assertions to
`HttpHeadersAssert`, since it cannot extend `AbstractMapAssert` anymore.
Closes gh-33913
This commit replaces NullAway package configuration by package-level
`@NullMarked` detection by configuring `NullAway:AnnotatedPackages` to
an empty string.
NullAway configuration should be refined to use a proper flag instead
once uber/NullAway#574 is fixed.
See gh-28797
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
This commit deprecates the `<mvc:*` XML configuration namespace for
configuring Spring MVC applications. This configuration model is lagging
behind in the 6.x generation already and we don't intend to invest in
this space to close that gap.
As of 7.0, using this XML namespace will result in a WARN log message.
This commit also states our intent in the reference documentation.
Closes gh-34063
This commit restores the original behavior of the clear() method in
TomcatHeadersAdapter by delegating to
org.apache.tomcat.util.http.MimeHeaders.recycle(), which aligns with
the memory efficiency goals documented in the class-level Javadoc for
MimeHeaders.
See gh-33916
Closes gh-34092
Spring Framework 7.0 will use a Kotlin 2 baseline, using the latest 2.x
release at the time of the release.
This commit upgrades Kotlin to 2.1.0, and Kotlin Serialization and
Coroutines accordingly.
Closes gh-33629
As a preparation to using a Kotlin 2 baseline, this commit stops using
Java code snippets in Kotlin ones in order to avoid redeclaration
errors.
See gh-33629
StandardWebSocketUpgradeStrategy is the common replacement on Tomcat, Undertow and all EE servers. JettyRequestUpgradeStrategy remains the preferred choice on Jetty.
Closes gh-33744
Includes removal of ManagedBean and javax.annotation legacy support.
Includes AbstractJson(Http)MessageConverter revision for Yasson 3.0.
Includes initial Hibernate ORM 7.0 upgrade.
Closes gh-34011
Closes gh-33750
This commit adapts AOT support in various modules after the RuntimeHints
and related deprecation changes.
`MemberCategory.INTROSPECT_*` hints are now removed and
`MemberCategory.*_FIELDS` are replaced with
`MemberCategory.INVOKE*_FIELDS` when invocation is needed.
Usage of `RuntimeHintsAgent` are also deprecated.
Closes gh-33847
This Java agent has been designed to instrument specific JDK calls for
reflective introspection and invocations. This is useful for testing
runtime hints in integration tests.
As of GraalVM 23, there is a new VM option that does this in a much more
efficient and precise fashion. Developers can use the
`-XX:MissingRegistrationReportingMode` with the "Warn" or "Exit" value.
The option will look for reachability metadata and emit logs in "Warn"
mode or immediately exit the application with in "Exit" mode.
This commit deprecates the `RuntimeHintsAgent` in favor of this new,
more reliable option.
See gh-33847
The `RuntimeHints` API mainly reflects what is needed to write GraalVM
reachability metadata. The latest GraalVM version simplified its
format. This commit applies relevant simplifications as parts of it are
not needed anymore.
The new metadata format implies methods, constructors and fields
introspection as soon as a reflection hint is registered for a type. As
a result, `ExecutableMode.INTROSPECT`, and all `MemberCategory` values
except `MemberCategory.INVOKE_*` are being deprecated.
They have no replacement, as registering a type hint is enough.
In practice, it is enough to replace this:
```
hints.reflection().registerType(MyType.class, MemberCategory.DECLARED_FIELDS);
```
By this:
```
hints.reflection().registerType(MyType.class);
```
As for `MemberCategory.PUBLIC_FIELDS` and `MemberCategory.DECLARED_FIELDS`,
values were replaced by `INVOKE_PUBLIC_FIELDS` and
`INVOKE_DECLARED_FIELDS` to make their original intent clearer and align
with the rest of the API. Note, if you were using those values for
reflection only, you can safely remove those hints in favor of a simple
type hint.
See gh-33847
As of GraalVM 23, a new and simplified reachability metadata format is
available. Metadata now consists of a single
"reachability-metadata.json" file that contains all the information
previously spread in multiple files. The new format does not include
some introspection flags, as they're now automatically included when a
hint is registered against a type.
Also, "typeReachable" has been renamed as "typeReached" to highlight the
fact that the event considered is the static initialization of the type,
not when the static analysis performed during native compilation is
reaching the type.
This new format ships with a JSON schema, which this commit is tested
against.
See gh-33847
Prior to this commit, the resource hints for AOT applications would
generate JSON metadata with `java.util.regex.Pattern`, like:
```
{
"resources": {
"includes": [
{
"pattern": "\\Qbanner.txt\\E"
}
]
}
}
```
This regexp feature, as well as "includes" and "excludes" are not supported
anymore with the new metadata format. This commit removes the pattern
format which is now replaced by a "glob" format.
"globs" should only contain "*" (zero or more characters in a path
segment) or "**" (zero or more path segments).
Some instances of resource hint registration should be migrated as a
result.
For example, "/files/*.ext" matched both "/files/a.ext" and
"/files/folder/b.txt" in the past. The new behavior matches only the
former, unless the "/files/**/*.ext" glob pattern is used.
This commit also removes the "excludes" support, which was not widely
used and very often could lead to subtle behavior.
Closes gh-31340
Prior to this commit, Spring would create directly
`SimpleMetadataReaderFactory` instances or would manually create
`CachingMetadataReaderFactory` which extend
`SimpleMetadataReaderFactory`. This would prevent usage of the new
`ClassFileMetadataReaderFactory` in our internal codebase.
This commit replaces manual instantiations with calls to
`MetadataReaderFactory` factory methods and makes
`CachingMetadataReaderFactory` delegate to another factory created with
the same factory methods.
This allows internal usage of `ClassFileMetadataReaderFactory`
internally.
Closes gh-33616
Prior to this commit, Spring Framework would allow two ways of getting
class metadata:
* `StandardClassMetadata`, using the Java reflection API
* `SimpleMetadataReaderFactory`, using ASM to read the class bytecode
This commit adds a new implementation for this feature, this time using
the new `ClassFile` API which is taken out of preview in Java 24.
See gh-33616
This commit adds a DSL Gradle extension for optionally enabling Java
preview features in a specific project module. The "--enable-preview"
JVM flag will be configured automatically for compile and test tasks
where this is applied:
```
springFramework {
enableJavaPreviewFeatures = true
}
```
See gh-33616
This commit upgrades our Mock Servlet classes for Servlet 6.1 support:
* the read/write `ByteBuffer` variants for `ServletInputStream` and
`ServletOutputStream` were not added as the default implementation
matches well the testing use case.
* Implement the session accessor with a simple lambda. Our mocks do not
simulate the scheduling of request/response processing on different
threads.
* Ensure that the response content length can only be written before the
response is committed. Calling those methods after commit is a no-op,
per specification.
Closes gh-33749
As of Servlet 6.1, the `ServletInputStream` and `ServletOutputStream`
offer read and write variants based on `ByteBuffer` instead of byte
arrays. This can improve performance and avoid memory copy for I/O
calls.
This was already partially supported for some servers like Tomcat
through specific adapters. This commit moves this support to the
standard `ServletHttpHandlerAdapter` and makes it available for all
Servlet 6.1+ containers.
Closes gh-33748
After our Tomcat 11 upgrade, several WebFlux integration tests with
Tomcat started failing because Tomcat considers some chunked client
requests as invalid.
While we're investigating this, this commit temporarily disables the
relevant tests.
See gh-33917
This commit upgrades the baseline to Tomcat 11.0 and adapts to the
following behavior changes in Tomcat:
* the MimeHeaders#clear method has been removed
* expired cookies do not set "Max-Age=0" anymore
* responses to HEAD requests do not write the "Content-Length" header
anymore.
Closes gh-33916
This commit updates the Spring Framework baseline for the Servlet, JSP
and WebSocket APIs.
This also removes the previously deprecated APIs in JSP `PageContext`
and guards against the deprecation of the `PushBuilder` API.
See gh-33918
`@Around("com.xyz.CommonPointcuts.businessService()")` references the `businessService` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
`@Around("com.xyz.CommonPointcuts.businessService()")` references the `businessService` named pointcut defined in
xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
Note that the aspect implements the `Ordered` interface so that we can set the precedence of
the aspect higher than the transaction advice (we want a fresh transaction each time we
The following example shows how to specify an argument name in XML:
[source,xml,indent=0,subs="verbatim"]
@@ -464,7 +456,8 @@ The following example shows how to specify an argument name in XML:
method="audit"
arg-names="auditable" />
----
<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
<1> References the `publicMethod` named pointcut defined in
Spring ships with a small AspectJ aspect library, which is available stand-alone in your
distribution as `spring-aspects.jar`. You need to add this to your classpath in order
to use the aspects in it. xref:core/aop/using-aspectj.adoc#aop-atconfigurable[Using AspectJ to Dependency Inject Domain Objects with Spring] and xref:core/aop/using-aspectj.adoc#aop-ajlib-other[Other Spring aspects for AspectJ] discuss the
content of this library and how you can use it. xref:core/aop/using-aspectj.adoc#aop-aj-configure[Configuring AspectJ Aspects by Using Spring IoC] discusses how to
dependency inject AspectJ aspects that are woven using the AspectJ compiler. Finally,
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework] provides an introduction to load-time weaving for Spring applications
that use AspectJ.
to use the aspects in it.
xref:core/aop/using-aspectj.adoc#aop-atconfigurable[Using AspectJ to Dependency Inject Domain Objects with Spring]
and xref:core/aop/using-aspectj.adoc#aop-ajlib-other[Other Spring aspects for AspectJ]
discuss the content of this library and how you can use it.
xref:core/aop/using-aspectj.adoc#aop-aj-configure[Configuring AspectJ Aspects by Using Spring IoC]
discusses how to dependency inject AspectJ aspects that are woven using the AspectJ compiler. Finally,
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework]
provides an introduction to load-time weaving for Spring applications that use AspectJ.
[[aop-atconfigurable]]
@@ -206,7 +208,6 @@ not use `@Configurable` on bean classes that are registered as regular Spring be
with the container. Doing so results in double initialization, once through the
container and once through the aspect.
[[aop-configurable-testing]]
=== Unit Testing `@Configurable` Objects
@@ -219,7 +220,6 @@ you can still unit test outside of the container as normal, but you see a warnin
message each time that you construct a `@Configurable` object indicating that it has
not been configured by Spring.
[[aop-configurable-container]]
=== Working with Multiple Application Contexts
@@ -249,7 +249,6 @@ is added only to the container-wide classpath (and hence loaded by the shared pa
not what you want).
[[aop-ajlib-other]]
== Other Spring aspects for AspectJ
@@ -302,7 +301,6 @@ fully qualified class names:
----
[[aop-aj-configure]]
== Configuring AspectJ Aspects by Using Spring IoC
@@ -357,7 +355,6 @@ results in the creation of Spring AOP proxies. The @AspectJ style of aspect
declaration is being used here, but the AspectJ runtime is not involved.
[[aop-aj-ltw]]
== Load-time Weaving with AspectJ in the Spring Framework
@@ -391,7 +388,6 @@ LTW that uses Spring, followed by detailed specifics about elements introduced i
example. For a complete example, see the
{petclinic-github-org}/spring-framework-petclinic[Petclinic sample application based on Spring Framework].
[[aop-aj-ltw-first-example]]
=== A First Example
@@ -677,7 +673,6 @@ nice example of a development-time aspect that developers can use during develop
and then easily exclude from builds of the application being deployed
into UAT or production.
[[aop-aj-ltw-the-aspects]]
=== Aspects
@@ -686,7 +681,6 @@ either the AspectJ language itself, or you can write your aspects in the @Aspect
Your aspects are then both valid AspectJ and Spring AOP aspects.
Furthermore, the compiled aspect classes need to be available on the classpath.
[[aop-aj-ltw-aop_dot_xml]]
=== `META-INF/aop.xml`
@@ -716,7 +710,6 @@ The structure and contents of this file is detailed in the LTW part of the
@@ -5,6 +5,7 @@ This chapter covers Spring's Ahead of Time (AOT) optimizations.
For AOT support specific to integration tests, see xref:testing/testcontext-framework/aot.adoc[Ahead of Time Support for Tests].
[[aot.introduction]]
== Introduction to Ahead of Time Optimizations
@@ -17,9 +18,9 @@ Applying such optimizations early implies the following restrictions:
* The beans defined in your application cannot change at runtime, meaning:
** `@Profile`, in particular profile-specific configuration, needs to be chosen at build time and is automatically enabled at runtime when AOT is enabled.
** `Environment` properties that impact the presence of a bean (`@Conditional`) are only considered at build time.
* Bean definitions with instance suppliers (lambdas or method references) cannot be transformed ahead-of-time.
* Bean definitions with instance suppliers (lambdas or method references) cannot be transformed aheadoftime.
* Beans registered as singletons (using `registerSingleton`, typically from
`ConfigurableListableBeanFactory`) cannot be transformed ahead-of-time either.
`ConfigurableListableBeanFactory`) cannot be transformed aheadoftime either.
* As we cannot rely on the instance, make sure that the bean type is as precise as
possible.
@@ -35,6 +36,7 @@ A Spring AOT processed application typically generates:
NOTE: At the moment, AOT is focused on allowing Spring applications to be deployed as native images using GraalVM.
We intend to support more JVM-based use cases in future generations.
[[aot.basics]]
== AOT Engine Overview
@@ -51,6 +53,7 @@ The `RuntimeHints` instance can also be used to generate the relevant GraalVM na
Those steps are covered in greater detail in the sections below.
[[aot.refresh]]
== Refresh for AOT Processing
@@ -88,6 +91,7 @@ This makes sure to create any proxy that will be required at runtime.
Once this part completes, the `BeanFactory` contains the bean definitions that are necessary for the application to run. It does not trigger bean instantiation but allows the AOT engine to inspect the beans that will be created at runtime.
[[aot.bean-factory-initialization-contributions]]
== Bean Factory Initialization AOT Contributions
@@ -106,11 +110,10 @@ Consequently, such a bean is automatically excluded from the AOT-optimized conte
[NOTE]
====
If a bean implements the `BeanFactoryInitializationAotProcessor` interface, the bean and **all** of its dependencies will be initialized during AOT processing.
We generally recommend that this interface is only implemented by infrastructure beans such as `BeanFactoryPostProcessor` which have limited dependencies and are already initialized early in the bean factory lifecycle.
We generally recommend that this interface is only implemented by infrastructure beans, such as a `BeanFactoryPostProcessor`, which have limited dependencies and are already initialized early in the bean factory lifecycle.
If such a bean is registered using an `@Bean` factory method, ensure the method is `static` so that its enclosing `@Configuration` class does not have to be initialized.
====
[[aot.bean-registration-contributions]]
=== Bean Registration AOT Contributions
@@ -127,7 +130,7 @@ Typically used when the bean definition needs to be tuned for specific features
[NOTE]
====
If a bean implements the `BeanRegistrationAotProcessor` interface, the bean and **all** of its dependencies will be initialized during AOT processing.
We generally recommend that this interface is only implemented by infrastructure beans such as `BeanFactoryPostProcessor` which have limited dependencies and are already initialized early in the bean factory lifecycle.
We generally recommend that this interface is only implemented by infrastructure beans, such as a `BeanFactoryPostProcessor`, which have limited dependencies and are already initialized early in the bean factory lifecycle.
If such a bean is registered using an `@Bean` factory method, ensure the method is `static` so that its enclosing `@Configuration` class does not have to be initialized.
====
@@ -219,21 +222,23 @@ NOTE: The exact code generated may differ depending on the exact nature of your
TIP: Each generated class is annotated with `org.springframework.aot.generate.Generated` to
identify them if they need to be excluded, for instance by static analysis tools.
The generated code above creates bean definitions equivalent to the `@Configuration` class, but in a direct way and without the use of reflection if at all possible.
The generated code above creates bean definitions equivalent to the `@Configuration` class, but in a direct way and without the use of reflection at all if possible.
There is a bean definition for `dataSourceConfiguration` and one for `dataSourceBean`.
When a `datasource` instance is required, a `BeanInstanceSupplier` is called.
This supplier invokes the `dataSource()` method on the `dataSourceConfiguration` bean.
[[aot.running]]
== Running with AOT Optimizations
AOT is a mandatory step to transform a Spring application to a native executable, so it
is automatically enabled when running in this mode. It is possible to use those optimizations
is automatically enabled when running within a native image. However it is also possible to use AOT optimizations
on the JVM by setting the `spring.aot.enabled` System property to `true`.
NOTE: When AOT optimizations are included, some decisions that have been taken at build-time
are hard-coded in the application setup. For instance, profiles that have been enabled at
build-time are automatically enabled at runtime as well.
NOTE: When AOT optimizations are included, some decisions that have been made at buildtime
are hardcoded in the application setup. For instance, profiles that have been enabled at
buildtime are automatically enabled at runtime as well.
[[aot.bestpractices]]
== Best Practices
@@ -271,7 +276,7 @@ build time.
While your application may interact with an interface that a bean implements, it is still very important to declare the most precise type.
The AOT engine performs additional checks on the bean type, such as detecting the presence of `@Autowired` members or lifecycle callback methods.
For `@Configuration` classes, make sure that the return type of the factory `@Bean` method is as precise as possible.
For `@Configuration` classes, make sure that the return type of an `@Bean` factory method is as precise as possible.
Consider the following example:
[tabs]
@@ -305,11 +310,11 @@ Kotlin::
----
======
In the example above, the declared type for the `myInterface` bean is `MyInterface`.
None of the usual post-processing will take `MyImplementation` into account.
For instance, if there is an annotated handler method on `MyImplementation` that the context should register, it won’t be detected upfront.
In the example above, the declared type for the `myInterface` bean is `MyInterface`.
During AOT processing, none of the usual post-processing will take `MyImplementation` into account.
For instance, if there is an annotated handler method on `MyImplementation` that the context should register, it will not be detected during AOT processing.
The example above should be rewritten as follows:
The example above should therefore be rewritten as follows:
[tabs]
======
@@ -348,7 +353,7 @@ If you are registering bean definitions programmatically, consider using `RootBe
=== Avoid Multiple Constructors
The container is able to choose the most appropriate constructor to use based on several candidates.
However, this is not a best practice and flagging the preferred constructor with `@Autowired` if necessary is preferred.
However, relying on that is not a best practice, and flagging the preferred constructor with `@Autowired` if necessary is preferred.
In case you are working on a code base that you cannot modify, you can set the {spring-framework-api}/beans/factory/support/AbstractBeanDefinition.html#PREFERRED_CONSTRUCTORS_ATTRIBUTE[`preferredConstructors` attribute] on the related bean definition to indicate which constructor should be used.
@@ -363,17 +368,17 @@ A good rule of thumb is to keep in mind that bean definitions are an abstraction
Rather than using such structures, decomposing to simple types or referring to a bean that is built as such is recommended.
As a last resort, you can implement your own `org.springframework.aot.generate.ValueCodeGenerator$Delegate`.
To use it, register its fullyqualified name in `META-INF/spring/aot.factories` using the `Delegate` as the key.
To use it, register its fully-qualified name in `META-INF/spring/aot.factories` using `org.springframework.aot.generate.ValueCodeGenerator$Delegate` as the key.
[[aot.bestpractices.custom-arguments]]
=== Avoid Creating Beans with Custom Arguments
Spring AOT detects what needs to be done to create a bean and translates that in generated code using an instance supplier.
The container also supports creating a bean with {spring-framework-api}++/beans/factory/BeanFactory.html#getBean(java.lang.String,java.lang.Object...)++[custom arguments] that leads to several issues with AOT:
Spring AOT detects what needs to be done to create a bean and translates that into generated code that uses an instance supplier.
The container also supports creating a bean with {spring-framework-api}++/beans/factory/BeanFactory.html#getBean(java.lang.String,java.lang.Object...)++[custom arguments] which can lead to several issues with AOT:
. The custom arguments require dynamic introspection of a matching constructor or factory method.
Those arguments cannot be detected by AOT, so the necessary reflection hints will have to be provided manually.
. By-passing the instance supplier means that all other optimizations after creation are skipped as well.
. Bypassing the instance supplier means that all other optimizations after creation are skipped as well.
For instance, autowiring on fields and methods will be skipped as they are handled in the instance supplier.
Rather than having prototype-scoped beans created with custom arguments, we recommend a manual factory pattern where a bean is responsible for the creation of the instance.
@@ -396,7 +401,7 @@ for further information.
=== FactoryBean
`FactoryBean` should be used with care as it introduces an intermediate layer in terms of bean type resolution that may not be conceptually necessary.
As a rule of thumb, if the `FactoryBean` instance does not hold long-term state and is not needed at a later point in time at runtime, it should be replaced by a regular factory method, possibly with a `FactoryBean` adapter layer on top (for declarative configuration purposes).
As a rule of thumb, if a `FactoryBean` instance does not hold long-term state and is not needed at a later point at runtime, it should be replaced by a regular `@Bean` factory method, possibly with a `FactoryBean` adapter layer on top (for declarative configuration purposes).
If your `FactoryBean` implementation does not resolve the object type (i.e. `T`), extra care is necessary.
Consider the following example:
@@ -455,7 +460,7 @@ Kotlin::
----
======
If the `FactoryBean` bean definition is registered programmatically, make sure to follow these steps:
If a `FactoryBean` bean definition is registered programmatically, make sure to follow these steps:
1. Use `RootBeanDefinition`.
2. Set the `beanClass` to the `FactoryBean` class so that AOT knows that it is an intermediate layer.
@@ -469,20 +474,20 @@ Java::
+
[source,java,indent=0,subs="verbatim,quotes"]
----
RootBeanDefinition beanDefinition = new RootBeanDefinition(ClientFactoryBean.class);
on any Spring bean or `@Bean` factory method. `RuntimeHintsRegistrar` implementations are
detected and invoked at build time.
include-code::./SpellCheckService[]
If at all possible, `@ImportRuntimeHints` should be used as close as possible to the component that requires the hints.
This way, if the component is not contributed to the `BeanFactory`, the hints won't be contributed either.
This way, if the component is not contributed to the `BeanFactory`, the hints will not be contributed either.
It is also possible to register an implementation statically by adding an entry in `META-INF/spring/aot.factories` with a key equal to the fully-qualified name of the `RuntimeHintsRegistrar` interface.
[[aot.hints.reflective]]
=== `@Reflective`
{spring-framework-api}/aot/hint/annotation/Reflective.html[`@Reflective`] provides an idiomatic way to flag the need for reflection on an annotated element.
For instance, `@EventListener` is meta-annotated with `@Reflective` since the underlying implementation invokes the annotated method using reflection.
Out-of-the-box, only Spring beans are considered but you can opt-in for scanning using `@ReflectiveScan`.
In the example below, all types of the package `com.example.app` and their subpackages are considered:
Out-of-the-box, only Spring beans are considered, but you can opt-in for scanning using
{spring-framework-api}/context/annotation/ReflectiveScan.html[`@ReflectiveScan`]. In the
example below, all types in the `com.example.app` package and its subpackages are
considered:
include-code::./MyConfiguration[]
Scanning happens during AOT processing and the types in the target packages do not need to have a class-level annotation to be considered.
This performs a "deep scan" and the presence of `@Reflective`, either directly or as a meta-annotation, is checked on types, fields, constructors, methods, and enclosed elements.
Scanning happens during AOT processing, and the types in the target packages do not need to have a class-level annotation to be considered.
This performs a _deep scan_, and the presence of `@Reflective`, either directly or as a meta-annotation, is checked on types, fields, constructors, methods, and enclosed elements.
By default, `@Reflective` registers an invocation hint for the annotated element.
This can be tuned by specifying a custom `ReflectiveProcessor` implementation via the `@Reflective` annotation.
@@ -634,13 +643,12 @@ This can be tuned by specifying a custom `ReflectiveProcessor` implementation vi
Library authors can reuse this annotation for their own purposes.
An example of such customization is covered in the next section.
[[aot.hints.register-reflection]]
=== `@RegisterReflection`
{spring-framework-api}/aot/hint/annotation/RegisterReflection.html[`@RegisterReflection`] is a specialization of `@Reflective` that provides a declarative way of registering reflection for arbitrary types.
{spring-framework-api}/aot/hint/annotation/RegisterReflection.html[`@RegisterReflection`] is a specialization of `@Reflective` that provides a declarative way to register reflection for arbitrary types.
NOTE: As a specialization of `@Reflective`, this is also detected if you're using `@ReflectiveScan`.
NOTE: As a specialization of `@Reflective`, `@RegisterReflection` is also detected if you are using `@ReflectiveScan`.
In the following example, public constructors and public methods can be invoked via reflection on `AccountService`:
`@RegisterReflection` can be applied to any target type at the class level, but it can also be applied directly to a method to better indicate where the hints are actually required.
`@RegisterReflection` can be used as a meta-annotation to provide more specific needs.
{spring-framework-api}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`] is such composed annotation and registers the need for serializing arbitrary types.
`@RegisterReflection` can be used as a meta-annotation to support more specific needs.
{spring-framework-api}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`] is a composed annotation that is meta-annotated with `@RegisterReflection` and registers the need for serializing arbitrary types.
A typical use case is the use of DTOs that the container cannot infer, such as using a web client within a method body.
The following example registers `Order` for serialization.
@@ -660,11 +668,66 @@ This registers hints for constructors, fields, properties, and record components
Hints are also registered for types transitively used on properties and record components.
In other words, if `Order` exposes others types, hints are registered for those as well.
[[aot.hints.convention-based-conversion]]
=== Runtime Hints for Convention-based Conversion
Although the core container provides built-in support for automatic conversion of many
common types (see xref:core/validation/convert.adoc[Spring Type Conversion]), some
conversions are supported via a convention-based algorithm that relies on reflection.
Specifically, if there is no explicit `Converter` registered with the `ConversionService`
for a particular source → target type pair, the internal `ObjectToObjectConverter`
will attempt to use conventions to convert a source object to a target type by delegating
to a method on the source object or to a static factory method or constructor on the
target type. Since this convention-based algorithm can be applied to arbitrary types at
runtime, the core container is not able to infer the runtime hints necessary to support
such reflection.
If you encounter convention-based conversion issues within a native image resulting from
lacking runtime hints, you can register the necessary hints programmatically. For
example, if your application requires a conversion from `java.time.Instant` to
`java.sql.Timestamp` and relies on `ObjectToObjectConverter` to invoke
`java.sql.Timestamp.from(Instant)` using reflection, you could implement a custom
`RuntimeHintsRegitrar` to support this use case within a native image, as demonstrated in
the following example.
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes"]
----
public class TimestampConversionRuntimeHints implements RuntimeHintsRegistrar {
public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
If no `list-class` attribute is supplied, the container chooses a `List` implementation.
[[xsd-schemas-util-map]]
=== Using `<util:map/>`
@@ -444,7 +438,6 @@ following configuration:
If no `'map-class'` attribute is supplied, the container chooses a `Map` implementation.
[[xsd-schemas-util-set]]
=== Using `<util:set/>`
@@ -500,7 +493,6 @@ following configuration:
If no `set-class` attribute is supplied, the container chooses a `Set` implementation.
[[xsd-schemas-aop]]
== The `aop` Schema
@@ -530,7 +522,6 @@ are available to you):
----
[[xsd-schemas-context]]
== The `context` Schema
@@ -555,7 +546,6 @@ available to you:
</beans>
----
[[xsd-schemas-context-pphc]]
=== Using `<property-placeholder/>`
@@ -599,34 +589,25 @@ element for that purpose. Similarly, Spring's
xref:integration/cache/annotations.adoc[caching annotations] need to be explicitly
xref:integration/cache/annotations.adoc#cache-annotation-enable[enabled] as well.
[[xsd-schemas-context-component-scan]]
=== Using `<component-scan/>`
This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration]
.
This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration].
[[xsd-schemas-context-ltw]]
=== Using `<load-time-weaver/>`
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework]
.
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework].
[[xsd-schemas-context-sc]]
=== Using `<spring-configured/>`
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring]
.
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring].
[[xsd-schemas-context-mbe]]
=== Using `<mbean-export/>`
This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export]
.
This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export].
[[xsd-schemas-beans]]
@@ -666,7 +647,3 @@ as it stands).
In the case of the preceding example, you could assume that there is some logic that consumes
the bean definition and sets up some caching infrastructure that uses the supplied metadata.
As a general rule, consider specifying the name with the annotation whenever other
components may be making explicit references to it. On the other hand, the
auto-generated names are adequate whenever the container is responsible for wiring.
[[beans-scanning-scope-resolver]]
== Providing a Scope for Autodetected Components
As with Spring-managed components in general, the default and most common scope for
autodetected components is `singleton`. However, sometimes you need a different scope
that can be specified by the `@Scope` annotation. You can provide the name of the
scope within the annotation, as the following example shows:
[tabs]
======
Java::
+
[source,java,indent=0,subs="verbatim,quotes"]
----
@Scope("prototype")
@Repository
public class MovieFinderImpl implements MovieFinder {
// ...
}
----
Kotlin::
+
[source,kotlin,indent=0,subs="verbatim,quotes"]
----
@Scope("prototype")
@Repository
class MovieFinderImpl : MovieFinder {
// ...
}
----
======
NOTE: `@Scope` annotations are only introspected on the concrete bean class (for annotated
components) or the factory method (for `@Bean` methods). In contrast to XML bean
definitions, there is no notion of bean definition inheritance, and inheritance
hierarchies at the class level are irrelevant for metadata purposes.
For details on web-specific scopes such as "`request`" or "`session`" in a Spring context,
see xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request, Session, Application, and WebSocket Scopes]. As with the pre-built annotations for those scopes,
you may also compose your own scoping annotations by using Spring's meta-annotation
approach: for example, a custom annotation meta-annotated with `@Scope("prototype")`,
possibly also declaring a custom scoped-proxy mode.
NOTE: To provide a custom strategy for scope resolution rather than relying on the
@@ -990,6 +980,7 @@ or ask for the `ApplicationStartup` type on any injection point.
NOTE: Developers should not use the `"spring.*"` namespace when creating custom startup steps.
This namespace is reserved for internal Spring usage and is subject to change.
[[context-create]]
== Convenient ApplicationContext Instantiation for Web Applications
@@ -1022,7 +1013,6 @@ Examples are `/WEB-INF/{asterisk}Context.xml` (for all files with names that end
(for all such files in any subdirectory of `WEB-INF`).
[[context-deploy-rar]]
== Deploying a Spring `ApplicationContext` as a Jakarta EE RAR File
@@ -1053,7 +1043,8 @@ all application classes into a RAR file (which is a standard JAR file with a dif
file extension).
. Add all required library JARs into the root of the RAR archive.
. Add a
`META-INF/ra.xml` deployment descriptor (as shown in the {spring-framework-api}/jca/context/SpringContextResourceAdapter.html[javadoc for `SpringContextResourceAdapter`])
`META-INF/ra.xml` deployment descriptor (as shown in the
{spring-framework-api}/jca/context/SpringContextResourceAdapter.html[javadoc for `SpringContextResourceAdapter`])
and the corresponding Spring XML bean definition file(s) (typically
`META-INF/applicationContext.xml`).
. Drop the resulting RAR file into your
@@ -1066,7 +1057,3 @@ other modules. A RAR-based `ApplicationContext` may also, for example, schedule
or react to new files in the file system (or the like). If it needs to allow synchronous
access from the outside, it could (for example) export RMI endpoints, which may be used
javadoc for more detail. For more on AspectJ load-time weaving, see xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework].
javadoc for more detail. For more on AspectJ load-time weaving, see
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework].
@@ -74,7 +74,6 @@ lead to concurrent access exceptions, inconsistent state in the bean container,
====
[[beans-definition-overriding]]
== Overriding Beans
@@ -100,11 +99,10 @@ the `@Bean` factory method in favor of any pre-declared constructor on the bean
****
NOTE: We acknowledge that overriding beans in test scenarios is convenient, and there is
explicit support for this as of Spring Framework 6.2. Please refer to
explicit support for this. Please refer to
xref:testing/testcontext-framework/bean-overriding.adoc[this section] for more details.
[[beans-beanname]]
== Naming Beans
@@ -147,7 +145,6 @@ case when there is more than one character and both the first and second charact
are upper case, the original casing gets preserved. These are the same rules as
defined by `java.beans.Introspector.decapitalize` (which Spring uses here).
[[beans-beanname-alias]]
=== Aliasing a Bean outside the Bean Definition
@@ -197,7 +194,6 @@ See xref:core/beans/java/bean-annotation.adoc[Using the `@Bean` Annotation] for
****
[[beans-factory-class]]
== Instantiating Beans
@@ -209,7 +205,8 @@ If you use XML-based configuration metadata, you specify the type (or class) of
that is to be instantiated in the `class` attribute of the `<bean/>` element. This
`class` attribute (which, internally, is a `Class` property on a `BeanDefinition`
instance) is usually mandatory. (For exceptions, see
xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[Instantiation by Using an Instance Factory Method] and xref:core/beans/child-bean-definitions.adoc[Bean Definition Inheritance].)
xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[Instantiation by Using an Instance Factory Method]
and xref:core/beans/child-bean-definitions.adoc[Bean Definition Inheritance].)
You can use the `Class` property in one of two ways:
* Typically, to specify the bean class to be constructed in the case where the container
@@ -233,7 +230,6 @@ a bean definition would be `com.example.SomeThing$OtherThing` or
`com.example.SomeThing.OtherThing`.
****
[[beans-factory-class-ctor]]
=== Instantiation with a Constructor
@@ -268,7 +264,6 @@ NOTE: In the case of constructor arguments, the container can select a correspon
constructor among several overloaded constructors. That said, to avoid ambiguities,
it is recommended to keep your constructor signatures as straightforward as possible.
[[beans-factory-class-static-factory-method]]
=== Instantiation with a Static Factory Method
@@ -346,7 +341,6 @@ overloads of the `mock` method. Choose the most specific variant of `mock` possi
----
====
[[beans-factory-class-instance-factory-method]]
=== Instantiation by Using an Instance Factory Method
@@ -494,5 +487,3 @@ The recommended way to find out about the actual runtime type of a particular be
a `BeanFactory.getType` call for the specified bean name. This takes all of the above
cases into account and returns the type of object that a `BeanFactory.getBean` call is
going to return for the same bean name.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Sam Brannen
