Re: [abc-dev] Extension

Hi Pavel,

Thanks for your help. I'm almost done with the extension. I just have one
last problem. It might be more related to Soot than Abc so sorry in advance
if that's the wrong mailing list. So, the problem is in my extension of
AspectCodeGen. I want to add a field of type java.util.ArrayList to
associable aspects. I've tried several different ways of getting a hold of a
SootClass for java.util.ArrayList but nothing seems to work, I always get an
error about the resolving level being HIERARCHY instead of SIGNATURES. I
read on the sable wiki that a way around that would be to add
java.util.ArrayList to the basic classes before calling abc.main.Main but
the problem is that this is the very first method called by abc so I'm not
sure how to go about it. Is there an easy way in Abc to load some classes at
a higher resolving level?

Thanks!

Albert

On 3/23/06, Pavel Avgustinov <pavel.avgustinov@magdalen.oxford.ac.uk> wrote:
>
> Hi,
>
> > My first question is where should I generate the code that creates the
> > List field inside the aspect? (Every associable aspect needs a static
> > List that keeps track of associated instances.) Should it go in a
> > ContextVisitor that visits all nodes until it finds an aspect that has
> > been marked as associable and then generate the code in enter()?
>
> Essentially, you're trying to introduce new static members onto the
> aspect class. A very similar case arises in pure AspectJ -- think of the
> static aspectOf() method that is added onto aspect classes.
>
> Since your Aspect.associate() and Aspect.disassociate() methods need to
> be visible to the base code, you need to introduce them (or at least
> stub methods that you fill in later) before method calls are resolved.
> The natural place for this is the AspectDecl_c class. Take a look at how
> it handles the aspectOf() method -- you'll need to do something very
> similar. Override AspectDecl_c in your extension, and override the
> factory that instantiates it so that it creates your updated class.
>
> The bodies of those methods can be generated whenever convenient; it
> might make sense to stick to the aspectOf() pattern. The body of that
> method is filled in in src/abc/weaving/weaver/AspectCodeGen.java, and
> happens on Jimple using Soot.
>
> > My second question is about the association Residue: I started writing
> > an IsAssociated residue that can be used for both 'this' and 'target'
> > association but I'm not sure how to refer back to the aspect from the
> > codeGen method. I would need to generate code that checks whether the
> > instance is in the List of that aspect before proceeding with the
> adivce.
>
> How you actually implement the isAssociated stuff is of course your
> choice, but note that if you introduce a method on the aspect class
> called "isAssociated(Object)", you can reduce the checks to if()
> pointcuts. Thus, you can rewrite your custom pointcuts to if() in the
> frontend.
>
> Note that if you want to do this globally, there is a mechanism for
> adding a new conjunct to every single pointcut. Thus, you could make all
> pointcuts respect aspect association. Take a look at
> src/abc/om/AbcExtension.java and its use of residueConjuncts.
>
> We gave a tutorial on extending abc at AOSD yesterday. The slides should
> appear on http://aspectbench.org sometime soon, in the meantime you can
> access a copy at http://musketeer.comlab.ox.ac.uk/~pavel/slides.pdf --
> there are some further explanations about residueConjuncts there, if
> nothing else.
>
> Apologies for the delay in this reply. Most of us are currently visiting
> the AOSD conference, so our access to email is somewhat sporadic. Hope
> this helps, feel free to ask for more information if you need it.
>
> Best wishes,
> Pavel
>
>
>
Received on Sat Apr 01 18:05:29 2006