Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] For tracing many ltw concrete-aspects or single one with lookup table

Hi,

A collection check made in the if() will be more costly than just a
boolean check, how about:

privileged aspect A1
{
   static boolean fooEnabled = false;
   static boolean barEnabled = false;
    static
    {
        // read config file to set boolean flags
    }

    pointcut foo(): if(fooEnabled) && execution(* Advised.foo());
    pointcut bar(): if(barEnabled) && execution(* Advised.bar());
    ...

would be more performant.

I'm not 100% confident in this:

    pointcut traced() : foo() || bar();

    before() : traced()

Might have to be careful here.  I hope it will correctly throw away
the invalid if() tests that can't possibly apply at each joinpoint.
Might be worth a quick check on bytecode (send it to me if you like)
to confirm just the right number of tests are done.

To avoid any problems you could have one piece of advice per joinpoint:

before(): foo() { helper(thisJoinPointStaticPart); }
before(): bar() { helper(thisJoinPointStaticPart); }

but hopefully the if checks will be optimized out as appropriate.

cheers,
Andy

On 28 February 2012 13:28, Hemal Pandya <hemal.pandya@xxxxxxxxx> wrote:
> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top