This commit reorders and clarifies the usage instructions for
ApplicationEvents to:
1. Recommend method parameter injection as the primary approach, since
ApplicationEvents has a per-method lifecycle
2. Clarify that ApplicationEvents is not a general Spring bean and
cannot be constructor-injected
3. Explicitly state that field injection is an alternative approach
This addresses confusion where developers expect ApplicationEvents to
behave like a regular Spring bean eligible for constructor injection.
See gh-35297
Closes gh-35335
Signed-off-by: khj68 <junthewise@gmail.com>
Prior to this commit, the MergedAnnotations support (specifically
AnnotationsScanner) and AnnotatedMethod did not find annotations on
overridden methods in type hierarchies with unresolved generics.
The reason for this is that ResolvableType.resolve() returns null for
such an unresolved type, which prevents the search algorithms from
considering such methods as override candidates.
For example, given the following type hierarchy, the compiler does not
generate a method corresponding to processOneAndTwo(Long, String) for
GenericInterfaceImpl. Nonetheless, one would expect an invocation of
processOneAndTwo(Long, String) to be @Transactional since it is
effectively an invocation of processOneAndTwo(Long, C) in
GenericAbstractSuperclass, which overrides/implements
processOneAndTwo(A, B) in GenericInterface, which is annotated with
@Transactional.
However, the MergedAnnotations infrastructure currently does not
determine that processOneAndTwo(Long, C) is @Transactional since it is
not able to determine that processOneAndTwo(Long, C) overrides
processOneAndTwo(A, B) because of the unresolved generic C.
interface GenericInterface<A, B> {
@Transactional
void processOneAndTwo(A value1, B value2);
}
abstract class GenericAbstractSuperclass<C> implements GenericInterface<Long, C> {
@Override
public void processOneAndTwo(Long value1, C value2) {
}
}
static GenericInterfaceImpl extends GenericAbstractSuperclass<String> {
}
To address such issues, this commit changes the logic in
AnnotationsScanner.hasSameGenericTypeParameters() and
AnnotatedMethod.isOverrideFor() so that they use
ResolvableType.toClass() instead of ResolvableType.resolve(). The
former returns Object.class for an unresolved generic which in turn
allows the search algorithms to properly detect method overrides in
such type hierarchies.
Closes gh-35342
Prior to this commit, ScriptUtils.executeSqlScript() treated every
statement within the script as if it were a single insert/update/delete
statement. This disregarded the fact that the execution of a JDBC
Statement can result in multiple individual statements, some of which
result in a ResultSet and others that result in an update count.
For example, when executing a stored procedure on Sybase, ScriptUtils
did not execute all statements within the stored procedure.
To address that, this commit revises the implementation of
ScriptUtils.executeSqlScript() so that it handles multiple results and
differentiates between result sets and update counts.
Closes gh-35248
Handle CancellationException in order to throw an HttpTimeoutException
when the timeout handler caused the cancellation.
See gh-34721
Signed-off-by: giampaolo <giampaorr@gmail.com>
fix: use timeoutHandler with a flag isTimeout
Closes gh-33973
Signed-off-by: giampaolo <giampaorr@gmail.com>
Refine the StringUtils#uriDecode method in the following ways:
- Use a StringBuilder instead of ByteArrayOutputStream, and only decode
%-encoded sequences.
- Use HexFormat.fromHexDigits to decode hex sequences.
- Decode to a byte array that is only allocated if encoded sequences are
encountered.
This commit adds another optimization mainly for the use case where
there is no encoded sequence, and updates the Javadoc of both
StringUtils#uriDecode and UriUtils#decode to match the implementation.
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Co-Authored-by: Sebastien Deleuze <sebastien.deleuze@broadcom.com>
Closes gh-35253
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>
Juergen Hoeller
Sam Brannen
khj68
Stefano Cordio
Stéphane Nicoll
rstoyanchev
秦利斌
giampaolo
Patrick Strawderman
Sébastien Deleuze
Brian Clozel
chenggwang