[
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 all,
to keep interested readers informed...
In cases you have the control over the design of the base code a small
redesign can help. I've tried to find a special feature for the children
collection itself (for example a filtered access) and specialized the
Collection (for example ArrayList) for the member field. The first I
wanted to have to not having my base design hooked to the aspects in any
way. With the second we can filter the specific calls to a member field
by the target type. Of course to mark every member in the base design
with a special class or interface becomes ugly. So this is not an
overall solution, but it works for my case. The pointcut declarations
look nice simple and I even like my base design better (a little ;)
Bruno
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Bruno Feurer
> Sent: Thursday, June 24, 2004 15:53
> To: aspectj-users@xxxxxxxxxxx
> Subject: 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
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
