Re: [aspectj-users] For tracing many ltw concrete-aspects or single one

[Hemal Pandya <hemal.pandya@xxxxxxxxx>]

Thank you Andy and Jean-louis.

The ability to define the entire aspect in aop.xml is very useful,
though not in my case as the users will not be able to write them. I
have realized they will not even be able to write just the joinpoints,
which means I cannot use a tool to create the jar either.

The approach I am settling down is a mix of the two I mentioned
earlier, I will appreciate very much any comments.

A single aspect will declare many pointcuts, one for each method that
we might want to introduce a delay on. On startup, the aspect will
read the "enabled" joinpoints from a configuration file. The pointcuts
will use an if() as well. This will also allow me to use use-friendly
names for the joinpoints instead of the entire signature:

privileged aspect A1
{
    static Set<String> ENABLED = new HashSet<String>();
    static
    {
        ENABLED.add("foo");
    }

    pointcut foo(): if(ENABLED.contains("foo")) && execution(* Advised.foo());
    pointcut bar(): if(ENABLED.contains("bar")) && execution(* Advised.bar());
    pointcut traced() : foo() || bar();

    before() : traced()
    {
        System.out.println("+++" + thisJoinPointStaticPart.getSignature());
    }
    after() : traced()
    {
        System.out.println("---" + thisJoinPointStaticPart.getSignature());
    }
}

Using this approach, it seems I will be able to -

- restrict the number of methods that will be advised
- allow the user to specify the methods to put a delay on
- even be able to change the methods on which there is a delay at
runtime (by checking timestamp on the file or listening on a socket)

Does this seem like a good approach?


Thanks and regards
Hemal

On Tue, Feb 28, 2012 at 8:33 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>
> Hi,
>
> 1.6.12 AspectJ does have a slightly more friendly way to build aspects
> in aop.xml - you don't need abstract aspects anymore, you can just use
> a java class containing methods and write the entire aspect in the
> aop.xml (effectively linking pointcuts to java methods).  This doesn't
> necessarily solve your issue here but I just thought it worth
> mentioning ( http://www.eclipse.org/aspectj/doc/released/README-1612.html
> ).
>
> You could instrument everywhere - the overhead would be similar to if
> you did it by hand (i.e. put a method call everywhere by hand).  It
> won't be free but if you use some kind of boolean guards on advice
> entry (or in an if() pointcut) before doing anything costly, you could
> keep overhead to a minimum.
>
> Would it be a suitable compromise to just work at the type level -
> avoid working with cryptic execution() pointcut method signatures and
> just have them think at the type level?  Pointcuts can be
>
>  "within(<sometypename>) && execution(* *(..));"
>
> but of course you'd then need to (in the advice) determine if it was a
> method you wanted to delay in that type or not.  It would just seem
> easier for a user to offer up typenames than method signatures.
>
> cheers
> Andy
>
>
>
> Andy
>
> On 27 February 2012 22:05, Hemal Pandya <hemal.pandya@xxxxxxxxx> wrote:
> > I am trying to develop a development framework where we can introduce a
> > delay at arbitrary but simple join-points. This is intended for some testing
> > related to concurrency and such-like.
> >
> > What I want to be able to do is, on different runs specify a method before
> > or after execution of which the thread should pause. For any run, I don't
> > expect the total pauses to be more then 10, if that many.
> >
> > I can think of two ways to do this and would appreciate very much any views
> > on their pros and cons.
> >
> > One approach is to define two abstract aspects, PauseBefore and PauseAfter.
> > In aop.xml concrete aspects are defined that extend one of the two. The
> > other approach is to have single Pause aspect that reads an external file
> > that lists the method names and before/after labels.
> >
> > The biggest problem with the abstract aspect approach is writing the
> > aop.xml. The runs will likely be done by others with no experience with
> > AspectJ or even programming, and I will need to build some kind of tool that
> > creates the aop.xml file and packages it correctly in a jar.
> >
> > With a single aspect I guess every method will have to be instrumented ,
> > which will that be too much of an overhead? If that can be compensated
> > somehow, I can think of many advantages, such as changing the configuration
> > on the fly without restarting the process, specifying the wait time.
> >
> > There must be middle-road that is the best approach, but I am not able to
> > see it. Any advice?
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users