Prior to this commit, the reference manual mentioned that the JSP
<form:input> tag supports HTML5-specific types, but the Javadoc and
spring-form.tld did not document the `type` attribute at all, and none
of the documentation explained which types are supported or that
<form:password> must be used for password fields.
This commit updates the documentation as follows.
- Document in InputTag, spring-form.tld, and the reference manual that
a `type` can be supplied as a dynamic attribute, that `checkbox` and
`radio` are not supported, and that the bound value is rendered as-is.
- Add notes to InputTag, the reference manual, and spring-form.tld
stating that <form:input type="password"> must not be used and that
<form:password> should be used instead.
- Document in PasswordInputTag, spring-form.tld, and the reference
manual that <form:password> does not render the bound value by default.
Closes gh-37376
Eclipse fails to infer the generic types in XmlEventDecoder and
DefaultWebClient, even though javac and IntelliJ IDEA compile the code
without issues.
This commit introduces explicit type arguments for the calls to
flatMapIterable() and exceptionWrappingFunction() to work around those
bugs.
- Remove redundant super() calls from constructors
- Add missing @Override annotations
- Use switch rules in JdkClientHttpRequest and RfcUriParser
- Use instanceof pattern matching
- Use method references instead of trivial lambda expressions
- Use lambda expressions instead of anonymous inner classes
- Remove unused code and redundant semicolons
- Use braces with if-blocks
This commit adds a test to MergedAnnotationsTests that verifies a
single primitive attribute in a composed annotation can be aliased via
@AliasFor to a primitive array attribute in a meta-annotation.
See gh-37349
Prior to this commit, `adaptForAttribute(Method, Object)` created
the wrapping array from `value.getClass()` when a single non-array
value was provided for an array attribute. This worked for object
array types but failed for primitive array types: wrapping a boxed
value produced a boxed array, which then failed the compatibility
check and threw an `IllegalStateException`.
This commit derives the component type from the declared attribute
type when it is assignable from the value type, falling back to
`value.getClass()` otherwise. The existing adaptation path for
object array types is therefore preserved, and all primitive array
types now accept a single value.
The accompanying test covers single-value wrapping for every array
type declared by ArrayTypes.
Closes gh-37349
Signed-off-by: Chengang Guan <guanchengang@qq.com>
computeIfAbsent registered the case-insensitive key before invoking the
mapping function. If the function returned null or threw an exception,
no mapping was recorded in the target map, but the key registration was
left behind. The map then reported containsKey(key) as true while size()
was 0, keySet() was empty, and get(key) returned null. A later insertion
with a different casing also reused the stale casing of the failed call,
since the existing-key branch resolved to the registered key.
The case-insensitive key is now only looked up up front. For a new key,
it is registered from within the mapping function once a non-null value
has been computed, which is still before the entry is inserted. A null
result or an exception therefore leaves both maps untouched, while a
removeEldestEntry override that evicts the new entry right away still
removes the registration, as it does for put. The existing-key path
keeps computing under the stored casing.
Closes gh-37351
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
KClass instances representing the same class are not guaranteed to be
identical, so the overridden function return type check introduced in
c39edeff15 could wrongly skip unboxing, for example when a class
implements an interface declaring the same suspending function.
See gh-37191
Only unbox value class results when the caller expects their unboxed
representation (non-primitive underlying type, non-nullable underlying
type for nullable return types, and no overridden function with a
different return type), and add related tests.
Cache the unbox method resolution per method and make it accessible
to support non-public value classes.
Closes gh-37191
Unbox Kotlin value class results returned from proxied suspending
methods before returning them to the caller.
Spring AOP interceptor chains expose return values as Object, which
causes Kotlin value class results to be boxed. For suspending functions,
the direct return path expects the unboxed value class representation.
Update both CglibAopProxy and JdkDynamicAopProxy to detect value class
return types and unbox boxed results after coroutine adaptation.
Add tests for suspending methods returning value classes.
See gh-37191
See gh-37155
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
Since Mockito 5.16.1, MockAccess moved from
org.mockito.internal.creation.bytebuddy.MockAccess to
org.mockito.internal.creation.bytebuddy.access.MockAccess.
Consequently, ProxyProcessorSupport.isInternalLanguageInterface() no
longer recognized it, causing an auto-proxied mock created with the
subclass mock maker and proxyTargetClass=false to receive a JDK proxy
that only implements MockAccess instead of a CGLIB proxy of its own
class.
This commit adds a check for the new package name alongside the
existing one, since older Mockito versions may still be on the
classpath.
Closes gh-37342
Prior to this commit, both `CssLinkResourceTransformer` implementations
could fail at runtime in case of invalid CSS links (for example, with
out of bounds exceptions).
This commit skips invalid links and writes them out to the resulting CSS
without any transformation.
Fixes gh-37336
Prior to this commit, `ResponseStatusException` would resolve the
"detail" part of a problem detail response from message codes only
(default or custom ones). If the `reason` given as an argument to the
exception was a custom message, it would be overwritten in the process.
This commit ensures that we use custom reason messages when they don't
resolve as message codes.
Fixes gh-36984
This commit documents the semantics for the `#result` SpEL expression
variable for a method that returns a Flux for @Cacheable and
@CachePut, both of which have always collected such a Flux's values
into a List. For such a method, `#result` refers to that List rather
than the Flux itself.
This commit addresses a number of unrelated inconsistencies in the
documentation as well.
See gh-37309
Prior to this commit, ReactiveCachingHandler.processCacheEvicts()
adapted every reactive return value via Mono.from(), which subscribes
for only the first element and cancels the upstream Publisher. For a
@CacheEvict method that returns a Flux, this silently truncated the
returned sequence to its first element. In addition, the `#result`
variable in `condition` SpEL expressions was bound to only that first
emitted element.
To address that, this commit mirrors the existing multi-value handling
in processPutRequest(). When the adapter reports isMultiValue(), a side
Subscriber is subscribed via publish().refCount(2) that exhausts the
Flux and collects its values into a List for eviction, while the
original, unmodified Flux is returned to the caller. Consequently, the
`#result` variable in `condition` SpEL expressions for a Flux-returning
@CacheEvict method is now the full List of emitted elements rather
than just the first element, making it consistent with @Cacheable and
@CachePut.
This commit also improves spr14235AdaptsToReactorFlux() in
CacheReproTests. Previously it exercised @CacheEvict only with a
single-element Flux and never asserted on the returned sequence. Now it
uses a multi-element Flux and verifies that all elements are both
returned to the caller and visible to the `condition` expression.
Last but not least, this commit documents the aforementioned
`#result`/Flux semantics in @CacheEvict's Javadoc and in the reference
manual, since both were previously invalid or incomplete for this
scenario.
Closes gh-37309
Both target-class tests asserted the target-interface counter,
leaving the intended pointcut unchecked. Assert the target-class
counter in both the XML and @AspectJ variants.
Closes gh-37310
Signed-off-by: itaekyung <taeyun1411@gmail.com>
The opaque-host percent-escape validation guard reads
input.codePointAt(i + 2) after only checking 'input.length() - i < 2',
so an input such as 'foo://%4' throws StringIndexOutOfBoundsException
instead of reporting a validation error.
Fix the bounds guard to require two code points after '%' and check
ASCII hex digits rather than ASCII digits, matching the URL spec, where
invalid percent-escapes in opaque hosts are validation errors, not
failures.
Signed-off-by: Sagar Chanchal <Sagarr2112@gmail.com>
Add a "Combining @Retryable with Other Proxy-Based Features" section
to the resilience reference documentation, covering interaction with
@Transactional, @Cacheable, and @Async, as well as advice order
customization between @Retryable and @Async via
@EnableResilientMethods(order) and @EnableAsync(order).
Also document the advice chain semantics in @Retryable Javadoc, add
cross-reference TIP blocks in the @Async, @Cacheable, and
@Transactional reference sections, add a @Cacheable combination test
to RetryInterceptorTests, and add RetryableTransactionTests in
spring-tx for the @Transactional combination.
See gh-35584
Closes gh-37005
Signed-off-by: jhan0121 <jhan0121@gmail.com>
ConcurrentLruCache.clear() previously drained write operations before
cleaning up the cache. This could re-enqueue nodes that clear() was
about to remove, causing useless evictionQueue operations. Now clear()
iterates the cache values directly, removes and marks nodes as removed
first, and drains write operations afterward. Since AddTask fails
silently after a node is marked removed, this avoids the no-op work
and improves performance.
See gh-37287
Closes gh-37292
Signed-off-by: Chengang Guan <guanchengang@qq.com>
`RetryTemplateTests` can, under load, break the build because of a flaky
test: "retryableWithTimeoutExceededAfterSecondRetry".
This usually happens when many cores are busy and the timeout check
runs before each retry attempt.
This commit extends the timeout to avoid such cases and failures.
Previously, PartGenerator only enforced maxDiskUsagePerPart for body
buffers that arrived after a part had switched to file storage. The
content accumulated in memory that triggered the switch was written
to disk without any check against maxDiskUsagePerPart. As a result,
a part whose last body buffer caused the in-memory overflow was
accepted in full, even when its total size exceeded the configured
disk usage limit.
This commit checks the accumulated byte count against
maxDiskUsagePerPart before switching to file storage, and emits a
DataBufferLimitException, consistent with the existing check for
subsequent buffers.
Closes gh-35099
Signed-off-by: seonghun lee <harrisleesh@gmail.com>
Prior to this commit, clear() polled the eviction queue to remove
entries and only afterward drained the pending write operations queue.
Consequently, a put() whose AddTask had not yet been linked into the
eviction queue -- for example, because it lost the race to self-drain
while clear() held the eviction lock -- would only be applied by that
trailing drain, linking the entry into the eviction queue right after
clear() had already finished removing everything it could see.
The practical effect was that an entry already fully added to the cache
could still be present immediately after clear() returned, with no
further concurrent activity required at that point.
To address that, this commit revises clear() so that it drains the
pending write operations queue before polling the eviction queue, so
any write that was already queued gets cleaned up along with everything
else. However, a put() that is genuinely concurrent with an in-progress
clear() call can still survive, which is consistent with the cache's
weak-consistency design.
Thanks to @guanchengang for raising gh-37286, which prompted this fix.
Closes gh-37287
markAsRemoved() transitions a node to the removed state and decrements
the current size, but it did not check whether the node had already
been removed. The eviction path and an explicit removal can process
the same node in sequence: when a write drain runs a queued AddTask
whose eviction polls a node that a concurrent remove(K) has already
taken out of the cache, the eviction decrements the size, and the
queued RemovalTask for the same node decrements it again. The sibling
transition markForRemoval() guards against invalid transitions; this one
did not.
Each extra decrement makes currentSize permanently smaller than the
number of cached entries, so eviction stops triggering and the cache
exceeds its capacity for good, silently. A bounded two-thread stress
run accumulates the drift reliably: before the change the cache
stabilized far above its capacity in 20 out of 20 runs.
markAsRemoved() now returns without decrementing when the entry is
already in the removed state, mirroring the guard in markForRemoval().
The removed state is terminal, so each node is counted down exactly
once. The new test races explicit removals against eviction and then
verifies that the cache converges back to its capacity; it also
asserts that the racing thread ran and terminated cleanly.
Closes gh-37268
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
This commit extends LazyConnectionInvocationHandler to cache early
calls to:
- setClientInfo(String, String)
- setNetworkTimeout(Executor, int)
These methods now defer physical connection acquisition until Statement
creation, consistent with existing lazy behavior for autoCommit,
readOnly, transactionIsolation, catalog, and schema.
We also accept and lazily cache calls to setNetworkTimeout() even when
the provided Executor is null. Since some JDBC driver implementations
completely ignore the Executor parameter (or fall back to a default
executor), we cannot meaningfully validate or handle a null Executor
before the physical connection is obtained.
getClientInfo() and getClientInfo(String) remain non-lazy (triggering
immediate connection fetch), because they are read operations whose
values cannot be reliably cached due to driver defaults, pooled
connection remnants, or external session modifications.
setClientInfo(Properties) also remains non-lazy. The reason is that JDBC
driver implementations are inconsistent. Some treat it as overwrite,
others as append/merge. To guarantee behavior identical to non-lazy
execution across all drivers, we choose not to cache or replay it,
avoiding any risk of semantic mismatch.
See gh-37258
Closes gh-37261
Signed-off-by: Chengang Guan <guanchengang@qq.com>
Since keySet() already applies the filter, size() evaluated the
predicate twice for every accepted key.
This commit uses delegate.keySet() instead, avoiding the second
evaluation as well as a FilteredSet and FilteredIterator allocation.
Closes gh-37256
Signed-off-by: Hyunwoo Jung <hyunwoojung@kakao.com>
Prior to this commit, LogAccessor's CharSequence-based logging methods
delegated directly to the corresponding method on the underlying
commons-logging Log instance without first checking whether the target
level was enabled. This differed from the Supplier-based overloads,
which have checked isXxxEnabled() before delegating since Spring
Framework 5.2.9.
That asymmetry was harmless as long as spring-jcl supplied the
underlying Log implementation, since its SLF4J adapter itself checked
the level before rendering the message. However, since Spring Framework
7 replaced spring-jcl with Apache commons-logging, whose SLF4J adapters
call String.valueOf(message) unconditionally, any CharSequence argument
-- most notably a LogMessage supplied via LogMessage.format(...) or
LogMessage.of(...) -- is now rendered eagerly, even when the
corresponding level is disabled. Since LogMessage exists specifically
to defer that work, and the idiom is used extensively throughout the
framework and its portfolio projects, this leads to unnecessary
computation and allocation whenever logging is disabled.
To address this, this commit adds the same isXxxEnabled() guard to all
twelve CharSequence-based methods in LogAccessor, matching the
existing Supplier-based overloads and making LogAccessor's laziness
guarantee independent of the underlying Log implementation.
This commit also introduces LogAccessorTests, which verifies that a
lazily rendering LogMessage passed to one of the CharSequence-based
methods is only rendered when the corresponding level is enabled.
See gh-25741
Closes gh-37266
Prior to this commit, gh-30953 fixed a case where multipart file parts
were not emitted properly when the body itself is empty.
There are other cases like this, depending on the order and slicing of
data buffers received by the parser. Here, a buffer containing the
entire boundary would not cause an empty file part to be emitted and
instead switch to the next header.
This commit ensures that empty file parts are always emitted as they
should.
Fixes gh-37264
The Mutiny Uni adapter registers its empty-value supplier as
Uni.createFrom().nothing(), which returns a Uni that never signals an
item, a failure, or completion. Every sibling registration supplies an
empty value that completes immediately: Mono.empty(), Maybe.empty(),
Completable.complete(), and CompletableDeferred(null); the Multi
registration uses Multi.createFrom().empty() as well.
ReactiveAdapter.toPublisher(null) substitutes that empty value whenever
a null source needs to be adapted, for example when a WebFlux handler
method with a Uni return type returns null. With a never-completing
empty value the resulting Publisher emits no signal at all, so the
response is never written and the request hangs until a timeout,
whereas the same handler declared with Mono completes empty. The
adapter also becomes asymmetric with its own fromPublisher function,
which adapts an empty Publisher to a Uni that completes with a null
item.
The supplier now uses Uni.createFrom().nullItem(), whose conversion to
a Publisher completes without emitting an item, matching the sibling
adapters and the round-trip through fromPublisher. The descriptor is
shared by the Mutiny 1 and Mutiny 2 registrations, so both paths are
covered.
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
Prior to this commit, Hibernate 8 types extending
`MutationOrSelectionQuery` would fail proxying at runtime in native
images because reflection hints were not registered at build time.
While the `MutationOrSelectionQueryImpl` case can be solved with an
additional proxy hint, `NativeMutationOrSelectionQueryImpl` is
impossible to solve that way due to multi interface mismatch.
This was found in gh-36878 and handled with a fallback proxy.
In this case, native image will throw a
`MissingReflectionRegistrationError` - but obviously we cannot depend on
this type in JVM applications. `MissingReflectionRegistrationError`
extends `LinkageError`, which we will use along
IllegalArgumentException` to detect that the proxying operation failed
and that we should use the fallback.
This commit also register a proxy hint for the said fallback.
Fixes gh-37251
Sam Brannen
Chengang Guan
김준형
Sébastien Deleuze
Dmitry Sulman
Tran Ngoc Nhan
Hyunwoo Jung
Brian Clozel
이태경
Juergen Hoeller
Sagar Chanchal
flinter
seonghun lee
junhyeong9812