This commit refactors some AssertJ assertions into more idiomatic and
readable ones. Using the dedicated assertion instead of a generic one
will produce more meaningful error messages.
For instance, consider collection size:
```
// expected: 5 but was: 2
assertThat(collection.size()).equals(5);
// Expected size: 5 but was: 2 in: [1, 2]
assertThat(collection).hasSize(5);
```
Closes gh-30104
This change fixes a situation where error handling was skipped during
`processCommit()` in case the `doCommit()` failed. The error handling
was set up via an `onErrorResume` operator that was nested inside a
`then(...)`, applied to an inner `Mono.empty()`. As a consequence,
it would never receive an error signal (effectively decoupling the
onErrorResume from the main chain).
This change simply moves the error handling back one level up. It also
simplifies the `doCommit` code a bit by getting rid of the steps that
artificially introduce a `Mono<Object>` return type, which is not really
needed.
A pre-existing test was missing the fact that the rollback didn't occur,
which is now fixed. Another dedicated test is introduced building upon
the `ReactiveTestTransactionManager` class.
Closes gh-30096
A failure to commit a reactive transaction will complete the
transaction and clean up resources. Executing a rollback at
that point is invalid, which causes an
IllegalTransactionStateException that masks the cause of the
commit failure.
This change restructures TransactionalOperatorImpl and
ReactiveTransactionSupport to avoid executing a rollback after
a failed commit. While there, the Mono transaction handling in
TransactionalOperator is simplified by moving it to a default
method on the interface.
Closes gh-27572
This commit ensures that CoroutineContext is properly
propagated in transactional suspending functions. Both
annotation and functional variants are supported.
Closes gh-27308
Before this commit, TransactionalOperator.executeAndAwait had a rigid
null-safety handling. This commit takes advantage of Kotlin capability
to allow to deal with both non-null and nullable depending on the
nullability of the lambda.
Closes gh-29919
Further refinements will be required for
MethodValidationPostProcessor since @Lazy
used by Spring Boot is not supported yet
for that use case.
See gh-28980
This commit replaces convention-based annotation attribute overrides in
tests with explicit use of @AliasFor -- except for tests in spring-core,
since we still want to test our support for convention-based annotation
attribute overrides.
See gh-28760
This commit introduces a TransactionBeanRegistrationAotProcessor
in charge of creating the required proxy and reflection hints
when @Transactional is detected on beans.
It also refines DefaultAopProxyFactory to throw an exception
when a subclass-based proxy is created in native images
since that's unsupported for now (see gh-28115 related issue).
Closes gh-28717
Prior to this commit, there was no way to configure type-safe rollback
rules for transactions.
Even though a rollback rule could be defined using a Class reference
via the `rollbackFor` and `noRollbackFor` attributes in @Transactional,
those Class references got converted to Strings (as the fully qualified
class names of the exception types) in RollbackRuleAttribute which then
applied a pattern-based matching algorithm as if the Class references
had been supplied as Strings/patterns to begin with, thereby losing the
type information.
Pattern-based rollback rules suffer from the following three categories
of unintentional matches.
- identically named exceptions in different packages when the pattern
does not include the package name -- for example,
example.client.WebException and example.server.WebException both
match against a "WebException" pattern.
- similarly named exceptions in the same package when a given exception
name starts with the name of another exception -- for example,
example.BusinessException and example.BusinessExceptionWithDetails
both match against an "example.BusinessException" pattern.
- nested exceptions when an exception type is declared in another
exception -- for example, example.BusinessException and
example.BusinessException$NestedException both match against an
"example.BusinessException" pattern.
This commit prevents the latter two categories of unintentional matches
for rollback rules defined using a Class reference by storing the
exceptionType in RollbackRuleAttribute and using that type in the
implementation of RollbackRuleAttribute.getDepth(Class, int), resulting
in type-safe rollback rules whenever the `rollbackFor` and
`noRollbackFor` attributes in `@Transactional` are used.
Note that the first category of unintentional matches never applied to
rollback rules created from a Class reference since the fully qualified
name of a Class reference always includes the package name.
Closes gh-28098
Krzysztof Krasoń
Sam Brannen
Simon Baslé
Enric Sala
Johnny Lim
Sébastien Deleuze
Kulwant Singh
Sam Brannen
Stephane Nicoll
Marc Wrobel
Rossen Stoyanchev
Juergen Hoeller