Expose AOP debugging information

[wouterdb]

Hi,

I attended the JBoss AOP session at AOSD 09 and learned there that the interfaces to JBoss AOP are being refactored. I think this is a good time to propose an introspective API for JBoss AOP.

With an introspective API it is possible to inspect all internal state of JBoss AOP that is relevant for application programmers, in terms of JBoss AOP abstractions. It shows how aspects integrate with the base code, which aspects are present, which bindings are present and who they are related. This allows for faster debugging by providing an opening in the black box.

In my work on AOP debugging (https://lirias.kuleuven.be/handle/123456789/222697) I have made a partial implementation of such an API. I support only method execution joinpoints and old style advices.

I would propose (at least) the following operations in the introspective API (per domain):

//aspects
AspectDefinition aspectForName(String aspectName)
List<AspectDefinition> allAspects()

//advices
InterceptorFactory advicesFor(AspectDefinition aspect)

//bindings
AdviceBinding bindingForName(String name)
List<AdviceBinding> allBindings()

//reverse operation of AdviceBinding.getInterceptorFactories()
List<AdviceBinding> bindingsFor(InterceptorFactory advice)

note 1: Advice applications indicate the presence of an advice on a certain joinpoint, caused by a certain binding. Thus an AdviceApplication references: an advice/InterceptorFactory, a binding/AdviceBinding, a cflow (residue/dynamic condition) and a joinpoint.

List<AdviceApplication> applicationsFor(Method m)
List<AdviceApplication> applicationsFor(Field m)
List<AdviceApplication> applicationsFor(Class clazz)

//for per instance AOP
List<AdviceApplication> applicationsFor(Object object)

List<AdviceApplication> applicationsFor(AdviceBinding binding)
List<AdviceApplication> applicationsFor(InterceptorFactory advice)


//JoinPoint
// get all joinpoints on/in a class/method/field
List<JoinPoint> joinPointsFor(Class m)
List<JoinPoint> joinPointsFor(Method m)
List<JoinPoint> joinPointsFor(Field m)

List<AdviceApplication> applicationsFor(JoinPoint joinpoint)
List<AdviceBinding> bindingsFor(JoinPoint joinpoint)

note 2 :Whether an advice applied to a field joinpoint is considered to be applied to the field or inside methods accessing the field and whether call joinpoints are part of the caller or the callee is unclear, this is open for discussion.

note 3 :It is (in some cases) possible to make these methods instance methods of their first argument, but it is beyond me whether this would be a good idea

If you would think such an API is a good thing to have and to build, the code of my implementation is available on http://distrinet.cs.kuleuven.be/software/AODA/versies/paper01/index.html in the packages JBoss Agent and JBoss Backend. The code for collecting some of the information is in JBossAgent adb.jagent.Agent. I could also give some pointers to similar things and perhaps some guidelines.

If you would think such an API is a good thing to have, but not to build, I'm willing to implement a first version myself, after note 2 and 3 have been resolved.

I hope I make sense,
Wouter

[kabirkhan]

Hi Wouter,

We don't have the manpower right now to add this ourselves. But if you are interested in adding this yourself, you are more than welcome to do so. Please mail me directly if you are interested, so we can go through the formalities needed to get you commit access.

"Wouterdb" wrote:
note 2 :Whether an advice applied to a field joinpoint is considered to be applied to the field or inside methods accessing the field and whether call joinpoints are part of the caller or the callee is unclear, this is open for discussion.

-the field joinpoint is considered to be applied to the field
-call joinpoints are part of the caller

"Wouterdb" wrote:
note 3 :It is (in some cases) possible to make these methods instance methods of their first argument, but it is beyond me whether this would be a good idea

If you mean instead of

List<AdviceApplication> applicationsFor(AdviceBinding binding)

doing

class AdviceBinding{
 ...
 List<AdviceApplication> applicationsFor()
}

I don't think that is a good idea, the introspective API should be as unintrusive as possible.