Hi, ok, your first two pointcuts aren't quite right:
First one: declare error: hasfield((@Injected *) *): "hit match1"; // try to simply match 'match1' as an @Injected field This is attempting to match when the type has a field whose type is marked @Injected. As far as I can see, that isn't what you want, you are interested in whether the field itself is annotated, not the type of the field. That would be simply: declare error: hasfield(@Injected * *): "hit match1"; // try to simply match 'match1' as an @Injected field Second one: declare error: hasfield(@Injected (!(@Managed *) *): "hit match2"; // try to match 'match2' as injection of a not @Managed type you are just missing a parentheses declare error: hasfield(@Injected (!(@Managed *)) *): "hit match2"; // try to match 'match2' as injection of a not @Managed type Third one, I think that is a bug related to compound type patterns. if you remove the within piece (and the &&) it behaves a little better. Feel free to raise a bugzilla for this problem. cheers Andy On 26 May 2011 15:10, Kristof Jozsa <kristof.jo...@gmail.com> wrote: > Hi Andy, > > thanks for your detailed answer. I understand you're dealing with a > limited set of resources so certainly I did not want to complain about > the lack of docs :) Now as you say, I checked the second edition of > AspectJ in Action I own and it mentions the hasmember features but in > about 10 lines as an experimental feature. > > At last I think I've found the unit tests I you mentioned in the Tools > CVS here: > http://dev.eclipse.org/viewcvs/viewvc.cgi/org.aspectj/modules/tests/?root=Tools_Project > and grepped around in them but unfortunately I still struggle with the > correct syntaxes of hasmember. > > Here's a test of the two use cases what I'm trying to accomplish (I > did turn on XhasMember both in ajdt and maven): > > public aspect HasMemberTest { > @Target(ElementType.FIELD) > @Retention(RetentionPolicy.RUNTIME) > public static @interface Injected { > } > > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public static @interface Managed { > } > > public static class Sample { > @Injected > private SampleManaged match1; > > @Injected > private String match2; > } > > @Managed > public static class SampleManaged { > public SampleManaged(int foo) {} > } > > declare error: hasfield((@Injected *) *): "hit match1"; // try to > simply match 'match1' as an @Injected field > declare error: hasfield(@Injected (!(@Managed *) *): "hit match2"; > // > try to match 'match2' as injection of a not @Managed type > declare error: within(@Managed *) && !hasmethod(new()) : "no default > constructor"; // try to match SampleManaged non-default constructor > } > > where the first declare fails to match and the other two is not > syntaxically correct in spite of I've spent a couple of hours now > trying to get them right (ok, the second one looks a bit too funky for > me as well). > > Is type pattern matching complete with annotation usage? > > thanks, > K > > > On Thu, May 26, 2011 at 6:06 PM, Andy Clement <andrew.clem...@gmail.com> > wrote: >> Hi, >> >> On 26 May 2011 01:36, Kristof Jozsa <kristof.jo...@gmail.com> wrote: >>> Hmm I wasn't yet aware of this hasmember feature. I tried to google >>> around and also checked my copy of Aspectj in Action but could not >>> find much examples. >> >> I can't recall if it was covered, but if it was it would be in the >> second edition (not the first) of AspectJ in action. Given that it is >> still an 'optional' feature, I'm not sure if Ramnivas did cover it or >> not. >> >>> Are there any usage details on hasfield/hasmethod somewhere? Also, is >>> there a unit test suite which I could check for examples? The AspectJ >>> source download doesn't seem to include any tests.. >> >> There are numerous tests in AspectJ for this. The source for the >> tests is not available in zip form though, it is only in the >> repository. The source zips downloadable alongside the distribution >> are only for what is in the distribution. Searching the source I see >> about 30/40 tests. >> >> The feature is actually described in this bug: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=86818 - which you'll >> actually see is still open. It is still open because you have to >> switch on this feature with -XhasMember, it still hasn't been made >> 'default'. It isn't default because it still doesn't play nicely with >> all the other language features (basically ITDs) - until it does it >> will still be something to opt into. >> >> But it was only in 1.6.9 that I added the ability to use type patterns >> with declare warning/error: >> http://www.eclipse.org/aspectj/doc/released/README-169.html >> >> --- >> It is now possible to use a type pattern with declare warning and >> declare error. For example: >> declare warning: I+ && !hasfield(int i): "Implementations of I are >> expected to have a int field called i"; >> --- >> I do acknowledge (and apologise that) the main docs don't cover it >> properly. We last had the resource to do a good docs update for 1.5.0 >> and that was all focussed on generics/annotations/etc when AspectJ was >> upgraded for Java5. Since then it is basically the sequence of >> READMEs that detail what has happened with AspectJ. >> >> Here is one of our testcases for it: >> === >> public aspect HasMethod { >> >> declare parents : hasmethod(* print(..)) implements Printable; >> >> public static void main(String[] args) { >> C c = new C(); >> if (! (c instanceof Printable)) { >> throw new RuntimeException("declare parents : >> hasmethod failed"); >> } >> } >> } >> >> class C { >> public void print() {} >> } >> >> interface Printable {}; >> === >> >> cheers >> Andy >> >>> On Wed, May 25, 2011 at 3:16 PM, Matthew Adams <matt...@matthewadams.me> >>> wrote: >>>> For the first one, you might try using "declare error" with a type >>>> pattern that uses hasmember. Not sure what you mean by the second, >>>> but declare error with hasmember might do the trick there, too. >>>> >>>> -matthew >>>> >>>> On Sat, May 21, 2011 at 5:57 PM, Kristof Jozsa <kristof.jo...@gmail.com> >>>> wrote: >>>>> I'd like to ask for help with two policy enforcement rules: >>>>> - enforce a class having no constructor with arguments (a default or a >>>>> parameterless constructor is fine) >>>>> - enforce an annotated field being of a certain type >>>>> >>>>> For the second one I currently enforce the get() of the field which is not >>>>> too bad, but would be nicer to disallow the field declaration.. if >>>>> possible. >>>>> >>>>> Can anyone show me an example doing these tricks? >>>>> >>>>> Thanks a lot, >>>>> K >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aspectj-users mailing list >>>>> aspectj-users@eclipse.org >>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> @matthewadams12 >>>> mailto:matt...@matthewadams.me >>>> skype:matthewadams12 >>>> yahoo:matthewadams >>>> aol:matthewadams12 >>>> google-talk:matthewadam...@gmail.com >>>> msn:matt...@matthewadams.me >>>> http://matthewadams.me >>>> http://www.linkedin.com/in/matthewadams >>>> _______________________________________________ >>>> aspectj-users mailing list >>>> aspectj-users@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>> >>> _______________________________________________ >>> aspectj-users mailing list >>> aspectj-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
