I tried to fix issue with Octave code autocompletion in Octclipse and ran into a difficult situation when I wasn't able to understand what is going on in internals.
Usually it is possible to use debugger for such purposes, but I was dealing with UI and this added me troubles - autocompletion popup is hidden on focus lost and it is not possible to use breakpoints. So, I decided to use trace technique, but I wanted to debug not my own code, but DLTK.
So, the only solution I knew for such a problem is Aspect Oriented Programming (AOP). It is well-known, how to use AspectJ for standalone application, there are also a lot of information on AOP in spring. But to introduce AOP in Eclipse plugins (which are OSGi based) those solutions are not applicable.
In general, there is a way to use Spring AOP in OSGi with Spring DM, but it is very heavy and I didn't want to setup that monster just to trace few method calls.
Fortunately, Eclipse Equinox has more lightweight solution for AOP, called Equinox Aspects. The quick start guide can be found at http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php .
I've gone through this manual, tested first aspects on the Octclipse project and then wrote a simple aspect like
before() : cflowbelow(execution(void net.sf.octclipse.internal.codeassist.OctaveCompletionEngine.complete(..))) &&
execution(* *.*(..)) && !within(TraceAspect){
try {
System.out.println(thisJoinPoint);
} catch (Exception e) {
}
}
Then, it is necessary to filter too low-level methods execution (for each specific case), and implement more comprehensive logic.
One more note, is that it is better to not use Require-Bundle for specifying plugins to weave, but Eclipse-SuplementBundle. In other case it is easy to run into an exception "error can't determine modifiersofmissing type". Sometimes it can be fixed with adding ";visibility:=reexport" to the bundle name in Require-Bundle directive, but someties - not.
Usually it is possible to use debugger for such purposes, but I was dealing with UI and this added me troubles - autocompletion popup is hidden on focus lost and it is not possible to use breakpoints. So, I decided to use trace technique, but I wanted to debug not my own code, but DLTK.
So, the only solution I knew for such a problem is Aspect Oriented Programming (AOP). It is well-known, how to use AspectJ for standalone application, there are also a lot of information on AOP in spring. But to introduce AOP in Eclipse plugins (which are OSGi based) those solutions are not applicable.
In general, there is a way to use Spring AOP in OSGi with Spring DM, but it is very heavy and I didn't want to setup that monster just to trace few method calls.
Fortunately, Eclipse Equinox has more lightweight solution for AOP, called Equinox Aspects. The quick start guide can be found at http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php .
I've gone through this manual, tested first aspects on the Octclipse project and then wrote a simple aspect like
before() : cflowbelow(execution(void net.sf.octclipse.internal.codeassist.OctaveCompletionEngine.complete(..))) &&
execution(* *.*(..)) && !within(TraceAspect){
try {
System.out.println(thisJoinPoint);
} catch (Exception e) {
}
}
Then, it is necessary to filter too low-level methods execution (for each specific case), and implement more comprehensive logic.
One more note, is that it is better to not use Require-Bundle for specifying plugins to weave, but Eclipse-SuplementBundle. In other case it is easy to run into an exception "error can't determine modifiersofmissing type". Sometimes it can be fixed with adding ";visibility:=reexport" to the bundle name in Require-Bundle directive, but someties - not.