src-spring-framework

Spring Framework

History

Sam Brannen c1033dbfb3 Support type-safe transaction rollback rules 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	3 years ago
..
src	Support type-safe transaction rollback rules	3 years ago
spring-tx.gradle	…

Sam Brannen c1033dbfb3 Support type-safe transaction rollback rules

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

3 years ago

src

Support type-safe transaction rollback rules

3 years ago

spring-tx.gradle

…