Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] How to prevent invocation or access of internal artifacts?

Hi Matthew,

I *think* the solution for this is tied up with the extended support
for if() pointcuts that is covered in that bug you raised:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=292262

> how can I
> say that the package of the accessing class must be in a package or
> subpackage of the field, method or constructor being accessed without
> hardcoding the package name?

in an ideal world you would delete your within clause and add
something a bit like this:

!if(thisEnclosingJoinPointStaticPart.getSignature().getDeclaringType().getPackage().getName().startsWith(thisJoinPointStaticPart.getSignature().getDeclaringType().getPackage().getName()))

Of course, that doesn't work today because if() can't be used in
declare error/warning.  In the bug you'll see I've started to think
about solutions that remove this restriction. I do not want to start
executing code that I am compiling as part of compilation (I never
like that strategy), so instead I would extend the list of supported
syntax in the if() that is statically optimized.  So far we only
optimize if(true) and if(false), but it wouldn't be rocket science to
support something like the above, it is a series of property accesses
and string 'startsWith' call.  A mini-EL if you like that is a subset
of Java which we would see if we could statically evaluate.  Straying
outside of the supported syntax would result in a message indicating
the if() can't be statically determined.

Andy

On 26 April 2010 14:42, Matthew Adams <matthew@xxxxxxxxxxxxxxx> wrote:
> Sometimes you need to make public, due to the fact that all members of
> interfaces are public, methods that you don't really want public, but
> need to be public inside the component you're writing (see C#'s
> "internal" keyword, which allows access to the indicated
> method/constructor/field from anything within the assembly but not
> from without).
>
> Here's an aspect that I hard coded with a package name to prevent any
> code compiled using AspectJ against my component from calling
> "internal" methods:
>
> =========
> /** Annotates a field, method, constructor or type as being not
> intended for public consumption */
> @Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
>                ElementType.CONSTRUCTOR })
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Internal {}
>
> =========
> privileged aspect InternalDeclareError {
>
>    declare error :
>                (!within(org.example.model..*))
>                        && (set(@Internal * *)
>                                || get(@Internal * *)
>                                || set(* (@Internal *).*)
>                                || get(* (@Internal *).*)
>                                || call(@Internal * *(..))
>                                || call(* (@Internal *..*).*(..))
>                                || call(@Internal *.new(..))
>                                || call((@Internal *).new(..))
>                )
>                : "The target constructor, method, or field in package
> org.example.model or one of its subpackages is not designed for public
> consumption; access is disallowed";
> }
> =========
>
> Note:  The goal is to have this checked at compile time, not run time.
>
> Question:  Assuming the use of the upcoming AspectJ 1.6.9, is there a
> way to write this aspect generically without having to hardcode the
> package (org.example.model in this case)?  In other words, how can I
> say that the package of the accessing class must be in a package or
> subpackage of the field, method or constructor being accessed without
> hardcoding the package name?
>
> Thanks,
> Matthew
>
> --
> mailto:matthew@xxxxxxxxxxxxxxx
> skype:matthewadams12
> yahoo:matthewadams
> aol:matthewadams12
> google-talk:matthewadams12@xxxxxxxxx
> msn:matthew@xxxxxxxxxxxxxxx
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>


Back to the top