Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-10596

Debugging difficulties in AspectJ LTW @Transactional methods

    Details

      Description

      Since 3.2.2, debugging @Transactional methods weaved with AspectJ is complicated (some might say "not possible").

      In version 3.2.2 AbstractTransactionAspect.aj was modified to use @around advice instead of the combination of @before and @after.

      After this change I cannot "Step Into" a @Transactional methods and then inside it, "Step Over" line by line.
      In Netbeans - this is the main IDE I use, it is possible to "Step Into" the method, but it is not possible to "Step Over" line by line inside the method.
      In Eclipse, if you to add a break point inside the method it is possible to step by step inside it, but
      for both, it is a problem, when the method ends, instead of getting back to the code that called this method, the debugger takes me to internal AOP/AspectJ classes.

      I'm tried different versions of AspectJ, 1.7.0, 1.7.1 and 1.7.2, for all of them the result is the same.

      Added a test project:
      https://github.com/dboldureanu/spring-framework-issues/tree/master/SPR-10596

      1. Put a break point at line 28, XmlConfigTests.java
      2. Start XmlConfigTests in debug mode.
      3. Step into saveTestData method and there try go line by line.
      Then try the same with an older version of Spring for example 3.2.1.

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        Sorry to hear that debugging seems to be so hard now....

        The change was motivated by full support for our (quite old) CallbackPreferringPlatformTransactionManager mechanism which wraps the entire target method call in a TransactionCallback, primarily designed for it to be compatible with WebSphere's UOWManager facility. We meant to do this change way earlier but only got reminded lately that we still had to do it.

        Not sure what we can do about this in the short term while also preserving support for WebSphere and potential other WebSphere-style transaction demarcation APIs. I'd say that AspectJ around advice should generally be easier to debug; I'll get in touch with our AspectJ guys and see what they say.

        Juergen

        Show
        juergen.hoeller Juergen Hoeller added a comment - Sorry to hear that debugging seems to be so hard now.... The change was motivated by full support for our (quite old) CallbackPreferringPlatformTransactionManager mechanism which wraps the entire target method call in a TransactionCallback, primarily designed for it to be compatible with WebSphere's UOWManager facility. We meant to do this change way earlier but only got reminded lately that we still had to do it. Not sure what we can do about this in the short term while also preserving support for WebSphere and potential other WebSphere-style transaction demarcation APIs. I'd say that AspectJ around advice should generally be easier to debug; I'll get in touch with our AspectJ guys and see what they say. Juergen
        Hide
        michaelwiles@gmail.com Michael Wiles added a comment -

        Yes, I have noticed this as well. I suspect it can probably be addressed on the "other" side as well (the eclipse AJDT plugin). Could it have something to do with the way the source code is mapped after the aspect has been weaved?

        Show
        michaelwiles@gmail.com Michael Wiles added a comment - Yes, I have noticed this as well. I suspect it can probably be addressed on the "other" side as well (the eclipse AJDT plugin). Could it have something to do with the way the source code is mapped after the aspect has been weaved?
        Hide
        dboldureanu Dumitru Boldureanu added a comment - - edited

        This seems to be an AspectJ issue, some other mentioning can found here: http://stackoverflow.com/questions/14762142/eclipse-debug-stepping-with-aspectj.

        From my experience methods that are weaved through @Before, @After, @AfterThrowing aspects are debugging fine, while those with @Around aren't.

        Show
        dboldureanu Dumitru Boldureanu added a comment - - edited This seems to be an AspectJ issue, some other mentioning can found here: http://stackoverflow.com/questions/14762142/eclipse-debug-stepping-with-aspectj . From my experience methods that are weaved through @Before, @After, @AfterThrowing aspects are debugging fine, while those with @Around aren't.
        Hide
        philvarner Phil Varner added a comment -

        It's not clear if this is an issue with AspectJ or the IDE (in my case IntelliJ IDEA), but it's probably not a problem with Spring. In the SO post that Dumitru linked to, a user asserts that "Stepping through advice has the incorrect file attribute attached to it." I don't know if that's true or not. In IntelliJ IDEA 13.0.1, the debugger does a pretty good job of linking the AspectJ woven code to the original line numbers – for example, within an @Transactional method, it will link a stack frame with a method name of foo_aroundBody2():440 to source file method foo():440 – which may just be a coincidence, and it only works b/c AspectJ is doing a good job of keeping the line numbers the same. For @Before and @Annotations, the IDEA debugger re-writes the frame stack to remove the aspectj frames and rename the woven methods to the original ones, so it looks as if the aspects don't exist. I've filed a case with IntelliJ to see if they can do the same for @Around.

        Show
        philvarner Phil Varner added a comment - It's not clear if this is an issue with AspectJ or the IDE (in my case IntelliJ IDEA), but it's probably not a problem with Spring. In the SO post that Dumitru linked to, a user asserts that "Stepping through advice has the incorrect file attribute attached to it." I don't know if that's true or not. In IntelliJ IDEA 13.0.1, the debugger does a pretty good job of linking the AspectJ woven code to the original line numbers – for example, within an @Transactional method, it will link a stack frame with a method name of foo_aroundBody2():440 to source file method foo():440 – which may just be a coincidence, and it only works b/c AspectJ is doing a good job of keeping the line numbers the same. For @Before and @Annotations, the IDEA debugger re-writes the frame stack to remove the aspectj frames and rename the woven methods to the original ones, so it looks as if the aspects don't exist. I've filed a case with IntelliJ to see if they can do the same for @Around.
        Hide
        philvarner Phil Varner added a comment -

        IntelliJ issue http://youtrack.jetbrains.com/issue/IDEA-119214 was filed to hopefully address this. As I said in my previous comment, it's not clear if AspectJ is generating sufficient metadata for @Around for the debugger to clean up the frame stack, but the IDEA developers should be able to figure that out.

        Show
        philvarner Phil Varner added a comment - IntelliJ issue http://youtrack.jetbrains.com/issue/IDEA-119214 was filed to hopefully address this. As I said in my previous comment, it's not clear if AspectJ is generating sufficient metadata for @Around for the debugger to clean up the frame stack, but the IDEA developers should be able to figure that out.

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            dboldureanu Dumitru Boldureanu
            Last updater:
            Phil Varner
          • Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Days since last comment:
              1 year, 33 weeks, 2 days ago