Re: [aspectj-users] RE: newbie: wildcards in pointcuts

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

> I want the aspect-compiler to give me feedback that
> the pointcut that the aspect references does not exist
> [when I am using wildcards]

If you mean something like...

  declare warning required: {pointcut} : {message};

  ajc emits {message} if {pointcut} is never matched.

...that could be an enhancement-request for the language
(submit a bug and provide some compelling use-cases).
But this would make sense only in a build cycle (not during
load-time or incremental weaving), so it probably belongs
in something like AJDT rather than aspectj proper.  On
that note, here's a slight reinterpretation:

  My pointcut is matching a join point, and I want to make
  sure it picks out that join point when I recompile
  {after making changes to the code or the pointcut},
  even if I am using wildcards in a PCD signature.

There's talk of a delta facility.  It would save a snapshot
from one build so you could compare it with the next.
If your pointcuts and the code have not changed, you'd expect
the pointcut shadows (the places where the compiler thinks
it has to implement a join point) will not have changed.
So any delta would be due to either the pointcut or the
code changing.  This delta would not identify differences
in the dynamic parts of the pointcut (unless the compiler
got smarter about which dynamic tests can safely be skipped).
Developers familiar with the AJDE structure model can imagine
how such a delta facility could be written.  (Again, doing this
as part of the toolset rather than in ajc permits ajc to
focus on per-class, per-join-point analysis.)

In practice this promises to have lots of false negatives,
but it's the only way I can think of to verify wildcard
pointcuts.

On the easier subject of debugging pointcuts, see also a
discussion in an aspectcookbook recipe:

  http://www.aspectcookbook.net/moin.cgi/DebugPointcutRecipe

Wes

Joost de Vries wrote:

> Hi Bill and Nicholas,
>
> Thanks for your feedback.
> During the weekend, outside of the project-deadline rush, I _did_ create a
> demo-version of what I want to do with aspectj. As Nicholas requested. And
> guess what: it worked the first time.
> So that made me start the new week with new vigor.
>
> I now find that my installation of eclipse 3M4 and AJDT 1.1.4 _does_ build
> my project but does _not_ update the classes that are used when I run the
> code.
> I guess that was the reason I did not get the whole thing working.
> So I'll just have to switch to using ant for compiling my aspects.
>
> My problems getting this to work made me wonder about the following:
> Using wildcards for pointcuts makes it inevitable that I only find out at
> runtime what classes/methods have been enhanced since the semantics of a
> wildcard are basically "for all methods that fit this wildcard". So if no
> methods do fit that's correct according to the aspect.
> But since my aspect is a critical part of the application, and not some
> add-on like logging, I want the aspect-compiler to give me feedback that
> the pointcut that the aspect references does not exist.
> In other words I think that I want to express an existential quantifier in
> my pointcut and not a universal quantifier. Or just refer to a unique
> metadata tag just like when I'm referencing a class.
> Of course the new metadata spec in JDK 1.5 is ideal for this. I seem to
> recall that Gregor is opposed to using metadata since the code that is
> being enhanced should not have knowledge of the fact that it is being
> enhanced.
> But since my aspects are a critical part of the application I'm developing
> there is no reason to avoid this construction. Both pieces of the code are
> under the control of the same development team.
> Actually not having the possibility to annotate the special semantics of
> my service methods forces me to use elaborate naming conventions that
> depend on the discipline of developers to keep uptodate with the aspect.
> Anyhow, thanks you guys,
>
> groetjes,
>
> Joost de Vries
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users