Using AOP to debug someone else's library
The topic of aspect-oriented programming (Aspect-oriented programming, AOP) has already been raised on Habré. This paradigm is not so few years old, but its use is far from universal. The comments regularly discusses whether it is needed at all or for what purpose it is still beneficial to use it.
In this article I want to describe one of the examples of application - the real situation where the AOP helped me out. Moreover, I simply do not know an acceptable solution without using aspects.
Have you ever encountered a situation where a bunch of your code with a third-party library or framework does not work? And there is a vague suspicion that you have a mistake somewhere, but it is difficult to find it without a debugger. And then suddenly it turns out that the library has no source, or for some other reason, debugging is not available ...
')
If you are wondering what can be done in such circumstances, welcome under cat.
Recently, while working on my open-source project, I encountered a similar problem when debugging autocompletion in the IDE based on the Eclipse DLTK (Dynamic Languages ToolKit).
I tried to use the debugger (all the sources, fortunately, were), but unfortunately, the error that I had to catch was hidden in the middle of the code for working with UI. And there is such a feature that the autocomplete window automatically closes when the focus is lost, that is, any breakpoints in that code and step-by-step debugging were excluded.
What can be done in such cases usually? You can use the trace. There are several well-known methods, ranging from debugging output, to full profiling. A list of these methods with a brief comparison can be found here . In this article, aspect-oriented programming is also mentioned (I would even say that there they were undeservedly credited with one minus).
So, a simple debugging output would require recompiling not only DLTK, but the entire JFace; proxies were not suitable due to the presence of private fields and methods; and the complete profiling of such a heavy platform as an eclipse is a sad prospect.
That's how I came to the need to use AOP.
It all turned out to be simple - I created a single aspect, which describes which calls to intercept, and what information to output to the console.
I do not want to describe the installation instructions and syntax basics. For AspectJ and PostSharp this introduction is already on Habré. In my case, the use of AOP in OSGi environment is a topic for a separate article in a more thematic blog.
I will only note that it was possible to connect the aspect without any intervention in the source code of the main project modules or platform libraries. It wasn’t even necessary to rebuild them (as stated by the article at the link above), because dynamic interweaving (runtime weaving) was used.
Finally, I also want to give a useful example on AspectJ, which in fact was my template for describing interception rules.
Trace all calls inside the call to the Foo.bar method:
Cutting too low-level calls can (and should) be done using cflowbelow negation, but this should already be done separately for each specific case.
The filtering capabilities of the required calls from AOP are very impressive . The only thing that confuses me in the above is the need to restart the application for the introduction of additional hooks.
Do not be afraid of AOP. However, tulit it everywhere, without the need, too, is not worth it. This is a very powerful tool with its scope. Its use in the context described in the article may seem like a nailing microscope, but in this case it was better than hammering it in with a hand or twisting it with a screwdriver.
But now I'm even thinking about how to encapsulate all this power in a small library for non-interactive debugging.
Anyway, the method described in the article helped me localize the problem and, I hope, can be useful to you in the future.
In this article I want to describe one of the examples of application - the real situation where the AOP helped me out. Moreover, I simply do not know an acceptable solution without using aspects.
Have you ever encountered a situation where a bunch of your code with a third-party library or framework does not work? And there is a vague suspicion that you have a mistake somewhere, but it is difficult to find it without a debugger. And then suddenly it turns out that the library has no source, or for some other reason, debugging is not available ...
')
If you are wondering what can be done in such circumstances, welcome under cat.
Problem
Recently, while working on my open-source project, I encountered a similar problem when debugging autocompletion in the IDE based on the Eclipse DLTK (Dynamic Languages ToolKit).
I tried to use the debugger (all the sources, fortunately, were), but unfortunately, the error that I had to catch was hidden in the middle of the code for working with UI. And there is such a feature that the autocomplete window automatically closes when the focus is lost, that is, any breakpoints in that code and step-by-step debugging were excluded.
What can be done in such cases usually? You can use the trace. There are several well-known methods, ranging from debugging output, to full profiling. A list of these methods with a brief comparison can be found here . In this article, aspect-oriented programming is also mentioned (I would even say that there they were undeservedly credited with one minus).
So, a simple debugging output would require recompiling not only DLTK, but the entire JFace; proxies were not suitable due to the presence of private fields and methods; and the complete profiling of such a heavy platform as an eclipse is a sad prospect.
That's how I came to the need to use AOP.
Decision
It all turned out to be simple - I created a single aspect, which describes which calls to intercept, and what information to output to the console.
I do not want to describe the installation instructions and syntax basics. For AspectJ and PostSharp this introduction is already on Habré. In my case, the use of AOP in OSGi environment is a topic for a separate article in a more thematic blog.
I will only note that it was possible to connect the aspect without any intervention in the source code of the main project modules or platform libraries. It wasn’t even necessary to rebuild them (as stated by the article at the link above), because dynamic interweaving (runtime weaving) was used.
Finally, I also want to give a useful example on AspectJ, which in fact was my template for describing interception rules.
Trace all calls inside the call to the Foo.bar method:
public aspect TraceAspect { before() : cflowbelow(execution(void Foo.bar(..))) && execution(* *.*(..)) && !within(TraceAspect){ try { System.out.println(thisJoinPoint.getSourceLocation()); } catch (Exception e) { } } } Cutting too low-level calls can (and should) be done using cflowbelow negation, but this should already be done separately for each specific case.
The filtering capabilities of the required calls from AOP are very impressive . The only thing that confuses me in the above is the need to restart the application for the introduction of additional hooks.
findings
Do not be afraid of AOP. However, tulit it everywhere, without the need, too, is not worth it. This is a very powerful tool with its scope. Its use in the context described in the article may seem like a nailing microscope, but in this case it was better than hammering it in with a hand or twisting it with a screwdriver.
But now I'm even thinking about how to encapsulate all this power in a small library for non-interactive debugging.
Anyway, the method described in the article helped me localize the problem and, I hope, can be useful to you in the future.
Source: https://habr.com/ru/post/138755/
All Articles