Debugging JBoss AOP Apps Tutorial - Part 3

This is the final part of our tutorial on debugging. In this part, we will show how to debug the overloaded-advices example step by step. This example comes bundled with JBoss AOP release, so all you need to do is to download the 2.0.0.GA release and start following the next steps.

First, create a project for the overloaded-advices tutorial example using Eclipse (the URL location is jboss-aop-2.0.0.GA/docs/aspect-framework/examples/overloaded-advices) and solve classpath issues by adding the JBoss AOP jars to the classpath (just include the jars of the jboss-aop-2.0.0.GA/lib directory).

Now, add a breakpoint to the Driver class, line 29, where there is a call to POJO constructor, the first joinpoint of the example that will be intercepted:

Configure a Java Application execution to run the Driver class, setting the AOP arguments as has been showed in the first part of this tutorial.

1. Start debugging this application.
2. Once Eclipse stops at line 29, press F5 to enter the constructor execution joinpoint. This is what you are going to see:










3. You see that the previous step resulted in a stack trace that shows a wrapper method belonging to the POJO class: POJO.POJO_new_$aop(), followed by the wrapper that is our focus of interest, the one belonging to the Advisor class: POJO$POJOAdvisor.POJOAdvisor_new_$aop().
   However, the top line of the stack is one of the “noises over the line” mentioned in the previous tutorial part. That line is a call to a ConstructorInfo method that returns some a sort of concurrency lock. So, press F7 to return to the Advisor wrapper method. Once you do this, you should see the stack trace below:
   










4. Whenever you are in the Advisor wrapper method, you should press F5. This is what we get once we press F5:












5. Oh no! Another “noise”. This time, more code handling locks. Now you know what to do. Press F7, return to the wrapper method, and press F5 on this wrapper until you enter a new block of code. Continue this process until you have finally entered the Joinpoint class.
   These are the “noises” you will run into during this process:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Note that the second “noise” (ConstructorInfo.hasAdvices()) will appear twice in a row.
   After step returning those “noise” elements with F7, Eclipse finally enters the first advice execution:
   












6. Once you get to the advice, debug it as you would normally. As this is a just tutorial, we are going to press F6 until we return to the Joinpoint class:
   












7. Back to the JoinPoint class. Press F5 until you find the next advice. Before getting there, you are going to run into another couple of “noise” elements:
   
   
   
   
   
   
   
   
   
   
   
   
   On the screen above, you see an info call at the top of the stack. As mentioned previously, this is something you should skip with F7. Right below it in the stack, there are three calls to constructors (<init> methods). Again, we have mentioned previously that calls to constructors should be skipped with F7. Skipping them and then pressing F5 will take you to the next advice:














8. You should debug this advice as you did in step 6, with F6. There is one line, however, that you must treat differently and press F5: line 39 of JoinPointAspect, containing the statement return invocation.invokeNext();
   
   This line, as you should know, is going to invoke the next around advice. If there are no around advice, it is going to call the joinpoint itself. So, if you want to debug the POJO constructor execution, you must enter the invocation.invokeNext() call. After pressing F5 in this line, you will see the following stack:
   













9. At this point, you have reached the joinpoint being intercepted. Whether it is a method or constructor, you can debug it as if this was a normal Java application. If it is a field set or a field get, you are not going to be able of debugging it though. But you can check the new value of the field after a field set joinpoint once you get back to your normal application at step 13.
   In this case, the joinpoint is a default constructor, so there are no lines to debug at all. Just press F6 to return to the previous item in the stack:
   














10. So, we are back to the Joinpoint class. Now, you should press F5 again following the tips given in step 5. Doing so will take us to the last advice:












11. Repeat step 6 now, pressing F6 to return to the Joinpoint class:
    












12. Pressing F5 now does not take us to the next advice,as all advice have already run. It takes us back to the advisor wrapper method.












13. You are done! Just press F7 twice to exit both wrappers and go back to the driver class. Now you can continue debugging. Try to enter the next joinpoints of the overloaded-advices example to see the other advice running! Remember that you must press F5 on field read and field write joinpoints, in order to enter their wrapper method code.

Next Steps

Once you have walked-through the steps to debug the overloaded-advices example, you are ready to debug any other JBoss AOP application you like. Try doing so using a different JBoss AOP tutorial, or just try debugging your own JBoss AOP application.

The next time you need to debug an application that uses JBoss AOP, I hope it is going to be easier for you to track bugs down with the tips we have presented in this tutorial. Good luck!