Enhance aspect to support superclass aspects

[JoshuaChen]

Summary:

1. Continue to fix the missing logic of parameter binding in PR Stop assuming that AspectJ Advice has JoinPoint as the first argument #34316
2. AspectJ correctly identifies the subclasses of abstract classes, fixing the failure of pointcut binding
3. Change the JointPoint in AbstractTransactionAspect.aj to ProceedingJoinPoint to fix the problem of parameter binding failure when calling @transaction at runtime

For more background, see PR #34316 and #34656

After this PR, the following exceptions have been fixed

2025-03-26T16:24:33.336+08:00 DEBUG 17613 --- [           main] o.s.a.aspectj.AspectJExpressionPointcut  : Pointcut parser rejected expression [transactionalMethodExecution(txObject)]: java.lang.IllegalArgumentException: Pointcut is not well-formed: expecting 'identifier' at character position 0

[jhoeller]

While this is definitely possible, I'm afraid we do not intend to go there. @EnableAspectJAutoProxy is only meant to deal with common @Aspect beans where such named pointcut indirection via inheritance is not a problem to deal with. Our management of different aspect types and different AspectJ usage scenarios is complex enough already.

Last but not least, we actually mean to ignore those weaving-only aspects for proxying purposes; that's by design. If @EnableTransactionManagement(mode=ASPECTJ) and @EnableAspectJAutoProxy are both declared, the former uses the transaction aspect for weaving purposes whereas the latter just looks at all custom @Aspect beans for proxying purposes. This is what the common intention is in existing applications, so we need to keep them separate.

So to be clear, we actually do not want our transaction aspect (or our similarly designed caching aspect) to be picked up by @EnableAspectJAutoProxy in such a setup since this would cause double invocation of the functionality around the same method: once from weaving and once from proxying. That's what our total exclusion of ajc-compiled aspects was for, and while this has been relaxed in the meantime, we still need to keep the weaving scenarios separate in common application setups.

So thanks for your efforts but please note that we do not intend to accept further revisions in this area.