Support standard javax.transaction.Transactional in AspectJ [SPR-11803] #16423
AnnotationTransactionAspect currently only has pointcuts for org.springframework.transaction.annotation.Transactional annotations. Please add support for javax.ejb.TransactionAttribute and javax.transaction.Transactional.
Referenced from: commits fa8d202
0 votes, 6 watchers
Juergen Hoeller commented
The problem here is that both the JTA 1.2 Transactional annotation and the EJB 3 TransactionAttribute annotation aren't reliably on the runtime classpath of a Spring-based application. It's a challenge to bake them into AnnotationTransactionAspect's pointcut declarations without enforcing a hard dependency.
This would be less concerning if it's easy to add those extra dependencies to the classpath, but unfortunately both of those annotations can be in conflict with pre-defined JTA and EJB API jars in older EE environments.
The 'trick' that we're applying for proxy-based transaction interception is simply to use reflection with runtime presence checks... Maybe there's a way to do this with AspectJ as well; what's your take on it, Andy Clement?
Andy Clement commented
If we did add those other transaction types to a pointcut, we do have some tech (when LTW) to turn off aspects when certain types are not around:
But that isn't very granular, it won't allow individual pointcuts to switch on and off depending on type availability. Which seems to be what we want here unless we want to construct multiple similar aspects?
You can do the reflective version using AspectJ that Juergen describes for proxies, but it'll be ugly:
Basically if we did add those types to the pointcuts in the transaction aspect, you are going to get typeNotFound messages at weave time (whenever that is). I have been thinking that typeNotFound is not necessarily the end of the world in all circumstances and maybe we need a way to indicate that to AspectJ. Right now you can dial down the message such that it is ignored but it is a separate step/flag that you need to tweak when consuming the library. What if we could:
If TransactionalA or TransactionalB is missing, this pointcut can still match if the other one is around. The suppression being expressed alongside the pointcut removes the problem of tweaking the message levels later (which is also a global switch, where this is a local switch). I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=436653 in AspectJ to cover doing something like this.