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

[Andy Clement <andrew.clement@xxxxxxxxx>]

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
>