Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Pointcut to calls to a specific field

Hi Wes,

thanks for your reply. As a beginner in AOP, I thought, I'm missing a
kind of feature here. Or maybe that would form a feature for future
releases. I mean, all the information for the weaver should be
statically available and situations when you are interested in field
specific calls could be plenty. What do you think?

For now I also came up with the idea of working with the control flow.
In fact I've just understood the difference between the cflow and
cflowbelow thing ;) So...

  call(boolean Collection.add(Object)) && cflow(get(Collection
MyContainer.children));

... limits the scope to only the code also referencing the field as
well. But we still got all the Collection.add() calls within these
methods. And the cflow seems to be a dynamic test as well.

I like your proxy approach, but in my case, I guess the overhead of the
proxy instance will be essential (lots of containers) or an allocation
at every access would lead into a performance issue.

The warning declaration part, I didn't understand. How would such a
declaration look like? I mean, if you can define all the "other
collections", you can define the ones needed as well, can't you?

cheers,
Bruno



> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx 
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Wes Isberg
> Sent: Thursday, June 24, 2004 0:36
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Pointcut to calls to a specific field
> 
> 
> Hi Bruno -
> 
> This is actually a really good example of thinking in terms 
> of join points (pointcuts, advice) and not code manipulation 
> or generation.  Though there is only one bit of code
> 
>      thing.field.add(something)
> 
> there are at least two join points (field-set, call).
> 
>  > I'm still not happy with the field test in the advice. Is 
> there really
>  > no static way to capture field specific join points?
> 
> The field-specific join points are get() and set().
> 
> The call join point only knows that it has a reference;
> it doesn't know that it is a field.  Conceptually you
> should think of it as different join points, something like
> 
>    load reference from field
>    make call
> 
> You pointed this out in saying
>  > I've
>  > found the get-access definition, but I don't see a way to 
> connect it to
>  > a following call.
> 
> As for this:
> 
>  > And the join point annotations in
>  > Eclipse still show up at the local Collection.add() calls.
> 
> As you point out, if() is a dynamic test, so the
> static shadow of the pointcut will be on all the
> call(boolean Collection.add(Object)) call join points.
> If the field is private, you could safely staticly limit
> the advised join points to calls within the declaring class:
> 
>    call(boolean Collection.add(Object)) && within(MyContainer)
> 
> If the field incidentally is the only collection, you might
> be able to combine within() and withincode() with call to 
> "accidentally" only specify calls to the field, and leave out 
> the dynamic if() test. In that case you might also specify 
> some declare-warnings to signal when other collections are 
> added to the class.  (This is not really an approach I 
> recommend, but I've seen it work for some situations.)
> 
> Another approach is to proxy the field and put the 
> crosscutting behavior in the proxy.  You'd use advice to 
> replace the field when it is set with your proxy that 
> delegates to a collection, and your proxy class would 
> implement whatever policy you needed.
> 
> Wes
> 
> Bruno Feurer wrote:
> 
> > Hi,
> > 
> > I'm still not happy with the field test in the advice. Is 
> there really 
> > no static way to capture field specific join points?
> > 
> > A new idea is to test the field reference within the pointcut
> > definition:
> > 
> >   pointcut add(MyContainer container, Object child, Collection c) :
> >       call(boolean Collection.add(Object)) && this(container) &&
> >       args(child) && target(c) && if(c == container.children);
> > 
> > This works also with a "clean" advice. But we still need the 
> > Collection parameter for the if statement. And the join point 
> > annotations in Eclipse still show up at the local Collection.add() 
> > calls.
> > 
> > Has somebody a hint or a correction to my approaches? There must be 
> > several situations for capturing calls to specific field 
> members. I've 
> > found the get-access definition, but I don't see a way to 
> connect it 
> > to a following call.
> > 
> > Thanks,
> > Bruno
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: aspectj-users-admin@xxxxxxxxxxx
> >>[mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Bruno Feurer
> >>Sent: Friday, June 18, 2004 16:16
> >>To: aspectj-users@xxxxxxxxxxx
> >>Subject: [aspectj-users] Pointcut to calls to a specific field
> >>
> >>
> >>Hi there,
> >>
> >>how can I define a pointcut picking out calls to specific field?
> >>
> >>  ...
> >>  this.children.add(someObj);
> >>  ...
> >>
> >>definitions like
> >>
> >>  pointcut add(MyContainer container, Object child) :
> >>      call(boolean Collection.add(Object)) && this(container)
> >>&& args(child);
> >>
> >>also match
> >>
> >>  ...
> >>  Collection c = new ArrayList();
> >>  c.add(someObject);
> >>  ...
> >>
> >>So I came up with the following solution:
> >>
> >>  pointcut add(MyContainer container, Object child, Collection c) :
> >>      call(boolean Collection.add(Object)) && this(container) &&
> >>args(child) && target(c);
> >>
> >>  after(MyContainer container, Object child, Collection c) :
> >>add(container, child, c) {
> >>      if (c != container.children)
> >>          return;
> >>      ...
> >>  }
> >>
> >>Has somebody found a better solution? Some definition
> >>limiting the pointcut only to a specified field or something alike?
> >>
> >>Thanks for any ideas,
> >>Bruno Feurer
> >>
> >>_______________________________________________
> >>aspectj-users mailing list
> >>aspectj-users@xxxxxxxxxxx
> >>http://dev.eclipse.org/mailman/listinfo/aspect> j-users
> >>
> > 
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx 
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/aspect> j-users
> 



Back to the top