Description
Jose Ignacio Gil Jaldo opened SPR-9375 and commented
I am not sure if it is intended to be a new feature or it is a bug, but since the @Transactional annotation is annotated as well as @Inherited, I would say it's more like a bug.
The situation is the following:
- Interface I
- Class A (abstract has JPA implementation methods, implements I).
- Class B (concrete and extending the class A) wants to take advantage of those methods.
There are more than 1 TransactionManager (one per module).
If I annotate the class B with @Transactional and try to use qualifier (to specify which transaction manager I want to use), it does not work. The problem seems to be in the class: AbstractFallbackTransactionAttributeSource in this snippet to be more specific:
// Second try is the transaction attribute on the target class.
txAtt = findTransactionAttribute(specificMethod.getDeclaringClass());
if (txAtt != null) {
return txAtt;
}there are 2 options, the comment is wrong or the code is wrong.
specificMethod.getDeclaringClass() is not the target class in my situation, is my abstract class A (because that one implements the methods).
A solution would be adding:
// Second try is the transaction attribute on the target class.
txAtt = findTransactionAttribute(userClass);
if (txAtt != null) {
return txAtt;
}Because that one would search in both userClass and specificMethod.getClass() since the annotation is @Inherited. It should be backwards compatible (except on the strange case of someone setting an annotation on both parent and child and expecting the one of the parent to be used, so the child one's would be 100% useless).
Affects: 3.1 GA
Reference URL: #106
1 votes, 3 watchers