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
Prior to this commit, MockCookie.parse() failed with an
IllegalArgumentException when attempting to parse a custom attribute
with a value, such as "Version=1". This is a regression that was
inadvertently introduced in 7fc4937199
when adding support for the "Partitioned" attribute which does not
support a value.
This commit addresses this regression by parsing both the name and the
value from an optional, custom attribute.
See gh-31454
Closes gh-34575
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 introduces a new loadContextForAotProcessing(...) variant
in AotContextLoader which accepts a RuntimeHints argument. This new
method is an interface default method which delegates to the existing
loadContextForAotProcessing(MergedContextConfiguration) variant for
backward compatibility.
In addition, the original loadContextForAotProcessing(...) variant is
now deprecated and has been converted to an interface default method
which throws an UnsupportedOperationException.
Note, however, that the framework now only invokes the new
loadContextForAotProcessing(...) variant within TestContextAotGenerator.
Closes gh-34513
This commit adds support for the Partitioned cookie attribute in the
reactive HTTP clients that support this: Reactor and HttpComponents.
Closes gh-34521
Signed-off-by: Rhett CfZhuang <dark.momo985@gmail.com>
[brian.clozel@broadcom.com: rework tests and support HttpComponents]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
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, `MockHttpServletResponse` would only support
adding a `Content-Language` once. Adding multiple header values would
always replace the content-language property in the response and the
entire header value.
This commit ensures that this behavior is supported.
Fixes gh-34488
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
Prior to this commit, the `DispatcherServlet` would try and reset the
response buffer in case of errors, if the response is not committed
already. This allows for more flexible error handling, even if the
response was being handled already when it errored.
Resetting the response buffer clears the body but leaves HTTP response
headers intact. This is done on purpose as to not clear headers
previously added by Servlet Filters. By leaving in place some headers
like "Content-Type", this does not take into account the fact that the
response body was cleared and that error handling will perform another
round of content negotiation. While this isn't a problem for some
Servlet containers which enforce a single "Content-Type" header value,
this can cause multiple/duplicate values for some others.
This commit ensures that the "Content-Type" response header is removed
at the same time as we clear the "producible media types" attribute:
another pass of content negotiation will be performed for error
handling.
Fixes gh-34366
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
Prior to this commit, calling `setHeader` on the response wrapper would
have a separate code path for the "Content-Length" header. This did not
support calls with `null` values and would result in an exception.
This commit ensures that the cached content length value is reset in
this case and that the call is forwarded properly to the superclass.
Fixes gh-34460
Prior to this commit, `MockHttpServletResponse#setHeader` would not
remove the header entry when given a `null` value, as documented in the
Servlet API.
This commit ensures that this behavior is enforced.
Fixes gh-34464
This commit adds an onRequest() hook to request more data from
the source in order to avoid hung uploads in MultipartParser.
Closes gh-34388
Signed-off-by: Gang Cheng <chenggangpro@gmail.com>
This commit adds missing `@since` tags for formField() and formFields in
MockHttpServletRequestDsl. See gh-34412 related issue.
Closes gh-34448
Signed-off-by: Johnny Lim <izeye@naver.com>
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
In order to avoid Gradle build warnings about @SuppressFBWarnings, this
commit introduces a testCompileOnly dependency on `findbugs` in the
spring-webmvc module so that the class file for @SuppressFBWarnings is
available to the compileTestJava task.
Closes gh-34418
Prior to this commit, @MockitoSpyBean could only be declared on fields
within test classes, which prevented developers from being able to
easily reuse spy configuration across a test suite.
With this commit, @MockitoSpyBean is now supported at the type level
on test classes, their superclasses, and interfaces implemented by
those classes. @MockitoSpyBean is also supported on enclosing classes
for @Nested test classes, their superclasses, and interfaces
implemented by those classes, while honoring @NestedTestConfiguration
semantics.
In addition, @MockitoSpyBean:
- has a new `types` attribute that can be used to declare the type or
types to spy when @MockitoSpyBean is declared at the type level
- can be declared as a repeatable annotation at the type level
- can be declared as a meta-annotation on a custom composed annotation
which can be reused across a test suite (see the @SharedSpies
example in the reference manual)
To support these new features, this commit also includes the following
changes.
- MockitoSpyBeanOverrideProcessor has been revised to support
@MockitoSpyBean at the type level.
- The "Bean Overriding in Tests" and "@MockitoBean and
@MockitoSpyBean" sections of the reference manual have been fully
revised.
See gh-34408
Closes gh-33925
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 an appropriate Converter was registered with
the ConversionService that converts from a POJO to an array and that
ConversionService was registered with the Spring Expression Language
(SpEL) TypeConverter, an attempt to invoke a varargs method in a SpEL
expression with such a POJO would fail because the ConversionService
was not used to convert the POJO to an array suitable for the varargs
method invocation.
This commit revises the implementations of convertArguments(...) and
convertAllMethodHandleArguments(...) in ReflectionHelper to support
such use cases.
Closes gh-34371
Prior to this commit, the order values of TestExecutionListener
implementations were hard-coded in their getOrder() methods.
To benefit users and integrators, this commit exposes those order values
as an ORDER constant in each TestExecutionListener.
See gh-34225
Closes gh-34404
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
Prior to this commit, if a String 'value' attribute of an annotation
was annotated with @AliasFor and explicitly configured to alias an
attribute other than @Component.value, the value was still used as the
@Component name, but the warning message that was logged stated that
the 'value' attribute should be annotated with
@AliasFor(annotation=Component.class). However, it is not possible to
annotate an annotation attribute twice with @AliasFor.
To address that, this commit revises the logic in
AnnotationBeanNameGenerator so that it issues a log message similar to
the following in such scenarios.
WARN o.s.c.a.AnnotationBeanNameGenerator - Although the 'value'
attribute in @example.MyStereotype declares @AliasFor for an
attribute other than @Component's 'value' attribute, the value is
still used as the @Component name based on convention. As of Spring
Framework 7.0, such a 'value' attribute will no longer be used as the
@Component name.
See gh-34346
Closes gh-34317
If the Servlet container delegates a disconnected client error via
AsyncListener#onError, wrap it as AsyncRequestNotUsableException
for more targeted and consistent handling of such errors.
Closes gh-34363
This commit ensures that `ContentDisposition` parses attributes like
"filename" and "filename*" in a case insensitive fashion, per RFC 6266.
Closes gh-34383
Signed-off-by: Andras Dobrosi <dobrosi@gmail.com>
[brian.clozel@broadcom.com: apply code conventions]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
Changes made to the Bean Override search algorithms in commit
9181cce65f resulted in a regression that caused tests to start failing
due to duplicate BeanOverrideHandlers under the following circumstances.
- An enclosing class (typically a top-level test class) declares a
@BeanOverride such as @MockitoBean.
- An inner class is declared in that enclosing class.
- A @Nested test class which extends that inner class is declared in
the same enclosing class.
The reason for the duplicate detection is that the current search
algorithm visits the common enclosing class twice.
To address that, this commit revises the search algorithm in
BeanOverrideHandler so that enclosing classes are only visited once.
See gh-33925
Closes gh-34324
Prior to this commit, test bean overrides (for example, @MockitoBean,
@TestBean, etc.) eagerly honored the name of the annotated field as a
fallback qualifier, effectively ignoring @Primary and @Fallback
semantics for certain use cases.
This led to situations where a bean override for a test would select a
different bean than the core container would for the same autowiring
metadata.
To address that, this commit revises the implementation of
BeanOverrideBeanFactoryPostProcessor so that @Primary and @Fallback
semantics are consistently honored before attempting to use the
annotated field's name as a fallback qualifier.
Closes gh-34374
Ensure the original instance is always the one returned no matter how
many times the HandlerMethod is re-created.
Make the constructor protected to allow subclasses to re-create the
HandlerMethod as the concrete subclass.
See gh-34375
Prior to this commit, `CronExpression` would support Quartz-style
expressions with "Nth occurence of a dayOfWeek" semantics by using the
`TemporalAdjusters.dayOfWeekInMonth` JDK support. This method will
return the Nth occurence starting with the month of the given temporal,
but in some cases will overflow to the next or previous month.
This behavior is not expected for our cron expression support.
This commit ensures that when an overflow happens (meaning, the
resulting date is not in the same month as the input temporal), we
should instead have another attempt at finding a valid month for this
expression.
Fixes gh-34360
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>
Due to changes in gh-19118, classes that contain @Lookup methods are
no longer required to be concrete classes for use with component
scanning; however, the reference documentation still states that such
classes must not be abstract.
This commit therefore removes the outdated reference documentation and
updates the corresponding Javadoc.
See gh-19118
Closes gh-34367
As of Spring Framework 6.2, the `RestClient.retrieve()` method is a
no-op and developers must invoke a terminal operation on the returned
`ResponseSpec` to have any side effect.
This has been documented in the Javadoc and the wiki release notes, but
this commit highlights this as well in the reference documentation.
Closes gh-34334
The changes in commit c20a2e4763 introduced a regression with regard to
binding to a Map property when the Map also happens to implement
Iterable.
Although that is perhaps not a very common scenario, this commit
reorders the if-blocks in AbstractNestablePropertyAccessor's
getPropertyValue(PropertyTokenHolder) method so that a Map is
considered before an Iterable, thereby allowing an Iterable-Map to be
accessed as a Map.
See gh-907
Closes gh-34332
Prior to this commit, several common HTTP headers were ignored from the
data binding process when collecting property values, in gh-34039 and
gh-34182.
This commit completes the initial enhancement by ensuring that the
default header predicate is also considering cases where constructor
binding is applied and the Java type has a lowercase variant of the HTTP
header name to filter.
Fixes gh-34292
This test was already ignored as of Java 21 because of a Java behavior
change, and now it started failing as of 17.0.14.
This commit removes the test entirely.
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 adds support for Kotlin properties in Spring WebMVC
controllers, supported for reasons explained in gh-31856, with
kotlinx.serialization converters.
Closes gh-34284
This commit adds support for Kotlin properties in Spring WebFlux
controllers, supported for reasons explained in gh-31856, with
kotlinx.serialization codecs.
See gh-34284
getFlag() returns true when the property is equal, ignoring case, to the
string "true", not just "true"; "TrUe" also means true.
Closes gh-34295
Signed-off-by: Mengqi Xu <2663479778@qq.com>
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
We now look for the target exception types in cause chain as well,
but return false if we encounter a RestClient or WebClient
exception in the chain.
Closes gh-34264
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 harmonizes how a candidate value is parsed to extract its
key and default, if any. Rather than returning {@code null} if no
default is available, `splitKeyAndValue` now consistently returns a
non-null array.
This prevents an escaped separator character to be mistakenly identified
as a placeholder in certain cases.
Closes gh-34289
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 reference documentation section explaining how
applications can use custom `HttpServiceArgumentResolver`
implementations to support complex application types as method
parameters in HTTP interfaces.
Closes gh-34227
For ComandLineArgs, supplying the same option multiple times with
different values is valid, and the values will be stored in a List.
This commit also updates the Javadoc for SimpleCommandLineArgsParser.
See gh-34282
Signed-off-by: puppy4c <puppy4c@foxmail.com>
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,13 +368,13 @@ 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.
@@ -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.
architectures that build upon the well-known Spring programming model.
[[context-functionality-events-annotation]]
=== Annotation-based Event Listeners
@@ -707,7 +704,6 @@ The `handleBlockedListEvent()` method publishes a new `ListUpdateEvent` for ever
`BlockedListEvent` that it handles. If you need to publish several events, you can return
a `Collection` or an array of events instead.
[[context-functionality-events-async]]
=== Asynchronous Listeners
@@ -754,7 +750,6 @@ Be aware of the following limitations when using asynchronous events:
See xref:integration/observability.adoc#observability.application-events[the `@EventListener` Observability section]
for more information on Observability concerns.
[[context-functionality-events-order]]
=== Ordering Listeners
@@ -786,7 +781,6 @@ Kotlin::
----
======
[[context-functionality-events-generics]]
=== Generic Events
@@ -880,7 +874,6 @@ for example, for processing all events asynchronously and/or for handling listen
----
[[context-functionality-resources]]
== Convenient Access to Low-level Resources
@@ -913,7 +906,6 @@ with special prefixes to force loading of definitions from the classpath or a UR
regardless of the actual context type.
[[context-functionality-startup]]
== Application Startup Tracking
@@ -990,6 +982,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 +1015,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 +1045,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 +1059,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].
@@ -57,9 +57,9 @@ The following table describes these properties:
In addition to bean definitions that contain information on how to create a specific
bean, the `ApplicationContext` implementations also permit the registration of existing
objects that are created outside the container (by users). This is done by accessing the
ApplicationContext's `BeanFactory` through the `getBeanFactory()` method, which returns
the `DefaultListableBeanFactory` implementation. `DefaultListableBeanFactory` supports
this registration through the `registerSingleton(..)` and `registerBeanDefinition(..)`
ApplicationContext's `BeanFactory` through the `getAutowireCapableBeanFactory()` method,
which returns the `DefaultListableBeanFactory` implementation. `DefaultListableBeanFactory`
supports this registration through the `registerSingleton(..)` and `registerBeanDefinition(..)`
methods. However, typical applications work solely with beans defined through regular
bean definition metadata.
@@ -74,7 +74,6 @@ lead to concurrent access exceptions, inconsistent state in the bean container,
====
[[beans-definition-overriding]]
== Overriding Beans
@@ -104,7 +103,6 @@ explicit support for this as of Spring Framework 6.2. 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
@@ -16,8 +16,9 @@ not know the location or class of the dependencies. As a result, your classes be
to test, particularly when the dependencies are on interfaces or abstract base classes,
which allow for stub or mock implementations to be used in unit tests.
DI exists in two major variants: xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based dependency injection]
and xref:core/beans/dependencies/factory-collaborators.adoc#beans-setter-injection[Setter-based dependency injection].
As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section], you can define bean
properties and constructor arguments as references to other managed beans (collaborators)
or as values defined inline. Spring's XML-based configuration metadata supports
sub-element types within its `<property/>` and `<constructor-arg/>` elements for this
purpose.
As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section],
you can define bean properties and constructor arguments as references to other managed beans
(collaborators) or as values defined inline. Spring's XML-based configuration metadata supports
sub-element types within its `<property/>` and `<constructor-arg/>` elements for this purpose.
[[beans-value-element]]
@@ -544,9 +543,10 @@ three approaches at the same time.
[[beans-c-namespace]]
== XML Shortcut with the c-namespace
Similar to the xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[XML Shortcut with the p-namespace], the c-namespace, introduced in Spring
3.1, allows inlined attributes for configuring the constructor arguments rather
then nested `constructor-arg` elements.
Similar to the
xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[XML Shortcut with the p-namespace],
the c-namespace, introduced in Spring 3.1, allows inlined attributes for configuring
the constructor arguments rather then nested `constructor-arg` elements.
The following example uses the `c:` namespace to do the same thing as the from
@@ -56,7 +56,6 @@ For instructions on how to register this or any other custom scope, see
xref:core/beans/factory-scopes.adoc#beans-factory-scopes-custom-using[Using a Custom Scope].
[[beans-factory-scopes-singleton]]
== The Singleton Scope
@@ -91,7 +90,6 @@ following example:
----
[[beans-factory-scopes-prototype]]
== The Prototype Scope
@@ -134,7 +132,6 @@ be handled by the client. (For details on the lifecycle of a bean in the Spring
container, see xref:core/beans/factory-nature.adoc#beans-factory-lifecycle[Lifecycle Callbacks].)
[[beans-factory-scopes-sing-prot-interaction]]
== Singleton Beans with Prototype-bean Dependencies
@@ -152,7 +149,6 @@ and injects its dependencies. If you need a new instance of a prototype bean at
runtime more than once, see xref:core/beans/dependencies/factory-method-injection.adoc[Method Injection].
[[beans-factory-scopes-other]]
== Request, Session, Application, and WebSocket Scopes
@@ -162,8 +158,6 @@ if you use a web-aware Spring `ApplicationContext` implementation (such as
such as the `ClassPathXmlApplicationContext`, an `IllegalStateException` that complains
about an unknown bean scope is thrown.
[[beans-factory-scopes-other-web-configuration]]
=== Initial Web Configuration
@@ -223,8 +217,6 @@ the same thing, namely bind the HTTP request object to the `Thread` that is serv
that request. This makes beans that are request- and session-scoped available further
down the call chain.
[[beans-factory-scopes-request]]
=== Request scope
@@ -272,8 +264,6 @@ Kotlin::
----
======
[[beans-factory-scopes-session]]
=== Session Scope
@@ -322,8 +312,6 @@ Kotlin::
----
======
[[beans-factory-scopes-application]]
=== Application Scope
@@ -371,8 +359,6 @@ Kotlin::
----
======
[[beans-factory-scopes-websocket]]
=== WebSocket Scope
@@ -380,8 +366,6 @@ WebSocket scope is associated with the lifecycle of a WebSocket session and appl
STOMP over WebSocket applications, see
xref:web/websocket/stomp/scope.adoc[WebSocket scope] for more details.
[[beans-factory-scopes-other-injection]]
=== Scoped Beans as Dependencies
@@ -539,8 +523,6 @@ interfaces. The following example shows a proxy based on an interface:
For more detailed information about choosing class-based or interface-based proxying,
see xref:core/aop/proxying.adoc[Proxying Mechanisms].
[[beans-factory-scopes-injection]]
=== Injecting Request/Session References Directly
@@ -553,7 +535,6 @@ objects which has the advantage of working in singleton beans and serializable b
as well, similar to scoped proxies for factory-scoped beans.
[[beans-factory-scopes-custom]]
== Custom Scopes
@@ -561,7 +542,6 @@ The bean scoping mechanism is extensible. You can define your own
scopes or even redefine existing scopes, although the latter is considered bad practice
and you cannot override the built-in `singleton` and `prototype` scopes.
[[beans-factory-scopes-custom-creating]]
=== Creating a Custom Scope
@@ -664,8 +644,6 @@ Kotlin::
This identifier is different for each scope. For a session scoped implementation, this
identifier can be the session identifier.
[[beans-factory-scopes-custom-using]]
=== Using a Custom Scope
@@ -773,7 +751,3 @@ of the scope. You can also do the `Scope` registration declaratively, by using t
NOTE: When you place `<aop:scoped-proxy/>` within a `<bean>` declaration for a
`FactoryBean` implementation, it is the factory bean itself that is scoped, not the object
returned from `getObject()`.
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.
Brian Clozel
