Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] suspicious super call interception

Hi,

I wrote my sample because you mentioned this:

> To my best knowledge, the two calls at (1) and (2) does the very same in Java,

and the sample showed that super.X() and X() can potentially do
different things depending on the hierarchy and what is overridden
where, so they are not always equivalent to each other (I know they
happen to do the same in your hierarchy, but not in every hierarchy) -
and perhaps that gives some insight as to why AspectJ is treating them
differently.

But, as I also mentioned in my email, there are no join points for
super calls, so you cannot match that call.  The best you can do right
now is use execution() instead - if the code containing the method is
accessible to the weaver (I suspect you'll say it isnt....).
The topic of whether to change weaver behaviour and allow interception
of super calls has come up a few times on the list but it has never
generated enough interest to lead to a real work item and get the
weaver changed.

cheers,
Andy

2009/9/28 Kristof Jozsa <kristof.jozsa@xxxxxxxxx>:
> Hi Andy,
>
> I think your sample is about something else. The code I pasted has a child
> class which in fact doesn't hold the method getting called, therefore
> methodcall() and super.methodcall() results in an identical behaviour just
> one of them gets weaved while the other doesn't.
>
> My target was to simply create a pointcut which can intercept childclasses
> of javax.xml.ws.Service calling their parent's getPort() method. See my
> original code:
>
> pointcut wsGetPortCall() :
>         call(Object javax.xml.ws.Service+.getPort(..));
>
> but this in fact behaved a bit differently as expected as it missed the
> cases where other programmers typed super.getPort() and not simply getPort()
> in their code (and they did not had a getPort() body overwriting the
> superclass' one). This was the barebone example code which demonstrates the
> exact problem I'm having:
>
> new Service(null, null) {
>     @SuppressWarnings("unused")
>     public void boo() {
>         super.getPort(null);    // (1)
>         getPort(null);             // (2)
>     }
> };
>
> I hope it makes more sense now. My question is how to accomplish my original
> goal? Is it possible?
>
> thanks,
> K
>
>
>
> On Mon, Sep 28, 2009 at 5:26 PM, Andy Clement <andrew.clement@xxxxxxxxx>
> wrote:
>>
>> public class A {
>>  public static void main(String []argv) {
>>    B b = new B();
>>    b.run();
>>  }
>> }
>>
>>
>> class Base {
>>  public void getPort() {
>>    System.out.println("Base.getPort()");
>>  }
>> }
>>
>> class B extends Base {
>>  public void run() {
>>    super.getPort();
>>    getPort();
>>  }
>>  public void getPort() {
>>    System.out.println("B.getPort()");
>>  }
>> }
>>
>> javac A.java
>> java A
>> Base.getPort()
>> B.getPort()
>>
>> they can do different things.  If your question is why your advice
>> didn't match, it is because super calls are not join points.  And that
>> is probably a hangover from the old days of source weaving I think,
>> which has just never been revisited.
>>
>> Andy
>>
>>
>> 2009/9/28 Kristof Jozsa <kristof.jozsa@xxxxxxxxx>:
>> > Sample code:
>> >
>> > public aspect WSPortFixerInterceptor {
>> >     pointcut wsGetPortCall() :
>> >         call(Object javax.xml.ws.Service+.getPort(..));
>> >
>> >     Object around() : wsGetPortCall() {
>> >         return
>> > WsClientTool.getInstance().fixWebServicePort(proceed());   //
>> > never mind this line
>> >     }
>> >
>> >
>> >     /** private inner class to verify correct interception */
>> >     @SuppressWarnings("unused")
>> >     private static class TestFixer {
>> >         {
>> >             new Service(null, null) {
>> >
>> >                 @SuppressWarnings("unused")
>> >                 public void boo() {
>> >                     super.getPort(null);    // (1)
>> >                     getPort(null);             // (2)
>> >                 }
>> >             };
>> >         }
>> >     }
>> > }
>> >
>> > To my best knowledge, the two calls at (1) and (2) does the very same in
>> > Java, but appearently (2) gets intercepted by this aspect and (1) does
>> > not..
>> > what's the explanation for this behaviour?
>> >
>> > thanks,
>> > K
>> >
>> > _______________________________________________
>> > 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