Hi Matthew, > I just realized that there's a bug in my pointcut -- I'm not > supporting the prevention of accessing any fields whose class is > annotated with @ProtectedInternal. How would I add that one, too?
set((@ProtectedInternal *) *) || get((@ProtectedInternal *) *) But the 'of the thing' part of your description makes it hard to specify the within in a general way. Obviously you can do it with a runtime test in some advice (or perhaps with an if() clause) but that prevents you using declare error. I can't think of how else to do it - maybe someone else can? But it doesn't seem entirely unreasonable - you just want the advise to be conditional on different properties of the same join point I wouldn't be against exploring what we can do here in the language with a few changes. I don't know what those changes would be however - perhaps we can do more static interpretation of if() clauses: if(!thisEnclosingJoinPoint.getPackage().equals(thisJoinPoint.getPackage)) or similar. Andy 2009/10/12 Matthew Adams <[email protected]>: > Well, that might help, but answering the question in the first message > of this thread will do nicely for now: > > At the line commented with GENERALIZE ME, I'd like to replace a > hard-coded type expression with one that effectively means "not within > the package of the thing (field, method, constructor or class) > annotated with @ProtectedInternal". > > public aspect ProtectedInternalDeclareError { > declare error : > (!within(org.foo.model.*)) // GENERALIZE ME > && (set(@ProtectedInternal * *) > || get(@ProtectedInternal * *) > || call(@ProtectedInternal * *(..)) > || call(* (@ProtectedInternal *..*).*(..)) > || call(@ProtectedInternal *.new(..)) > || call((@ProtectedInternal *).new(..)) > ) > : "The target constructor, method, or field is not designed for > public consumption; access is disallowed."; > } > > I just realized that there's a bug in my pointcut -- I'm not > supporting the prevention of accessing any fields whose class is > annotated with @ProtectedInternal. How would I add that one, too? > > Thanks, > Matthew > > On Sat, Oct 10, 2009 at 8:05 PM, Andrew Eisenberg <[email protected]> wrote: >> Hi Matthew, >> >> I don't know how much control you have over the code you are trying to >> enforce API usage on, but OSGi + Eclipse's API tooling might be a help >> here: >> http://wiki.eclipse.org/ApiTools_Architecture >> >> Essentially, the API tooling allows you to add JavaDoc tags (yes, >> Eclipse internals are still using 1.4, so no annotations) that >> describe how other plugins can consume classes in the current plugin. >> Eg- @noreference, @noimplement, @noextend, etc. >> >> On Sat, Oct 10, 2009 at 7:19 AM, Matthew Adams <[email protected]> >> wrote: >>> BTW, now that I think about it, even in OSGi, I'm not sure this solves >>> my problem, because OSGi bundles export packages, not individual >>> classes or methods, and my problem exists at the method visibility >>> level across several classes within the package. >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > > > > -- > mailto:[email protected] > skype:matthewadams12 > yahoo:matthewadams > aol:matthewadams12 > google-talk:[email protected] > msn:[email protected] > http://matthewadams.me > http://www.linkedin.com/in/matthewadams > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
