[
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
>