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, JdbcClient's BatchSpec bound parameters to a
"current" batch entry and separated consecutive entries via add(). That
style was error-prone, since a missing add() still compiled but
silently merged parameters into a single entry. It also did not lend
itself to providing batch parameters dynamically — for example, from an
existing collection of domain objects.
To address that, this commit replaces the chaining style with
self-contained batch entries. BatchSpec now provides entry(...) methods
that define a single entry — via a Consumer<BatchEntry> callback, a
List of positional parameters, or a Map of named parameters — as well
as entries(...) methods that define one entry per parameter object.
Such calls can be freely combined within the same batch.
The new BatchEntry type exposes only the singular param(...) and
paramSource(...) methods. The add() method as well as the param(...),
params(...), and paramSource(...) methods have been removed from
BatchSpec.
Closes gh-37341
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
`batchArgs[0]` in `NamedParameterJdbcTemplate` and `indexedBatch[0]` in
`DefaultJdbcClient` are already set by
`pscf::newPreparedStatementCreator`, so it is unnecessary to set them
again via `BatchPreparedStatementSetter::setValues`.
Closes gh-37308
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
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>
Prior to this commit, `DefaultFormattingConversionService` would
register converters with both `DateTimeFormatterRegistrar` and
`DateFormatterRegistrar`, the former also registering the legace date
converters that the latter contributes.
While we cannot change the behavior for `DateTimeFormatterRegistrar` or
`DateFormatterRegistrar` because of their public contract, we can update
the `DefaultFormattingConversionService` to not use
`DateFormatterRegistrar` and register manually the annotation support
that it contributes.
Closes gh-36951
Introduce a fluent batch() operation on JdbcClient.StatementSpec that
accumulates several sets of parameters - bound as positional or named
parameters in the same fashion as a single update, separated by add() -
and executes them as a single JDBC batch through update(). Batch updates
previously required dropping down to (NamedParameter)JdbcTemplate.
Closes gh-37216
Co-authored-by: Jiří Krokviak <j.krokviak@gmail.com>
Signed-off-by: Jiří Krokviak <j.krokviak@gmail.com>
Signed-off-by: Yanming Zhou <zhouyanming@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>