Ok I see where the misunderstanding came from - sorry I wasn't clear enough
on the first run. Thanks for your help and the explanation, I'll remember
that limitation in the future.

rgds,
K


On Mon, Sep 28, 2009 at 9:45 PM, Andy Clement <[email protected]>wrote:

> 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 <[email protected]>:
> > 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 <[email protected]>
> > 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 <[email protected]>:
> >> > 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
> >> > [email protected]
> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >> >
> >> >
> >> _______________________________________________
> >> aspectj-users mailing list
> >> [email protected]
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Reply via email to