Re: [aspectj-users] protected inter-type methods

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Reid,

As Ron points out the visibility modifiers for ITDs are WRT the declaring
aspect not the target type. Does the subclass not give you the modularity
you need? You can always define an inner-aspect within the subclass to
implement any necessary dynamic cross-cutting.

BTW do you need the subclass? Would call advice not work instead?

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

"Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>@eclipse.org on 24/10/2004 17:43:55

Please respond to aspectj-users@xxxxxxxxxxx

Sent by:    aspectj-users-admin@xxxxxxxxxxx


To:    aspectj-users@xxxxxxxxxxx
cc:
Subject:    Re: [aspectj-users] protected inter-type methods


Hi Reid,

First off, there is a better pattern/work around for what you're trying to
do, in many cases. You can define a subclass of the library class and
override the protected method there to just do a supercall. Then you can
use declare parents to make any of your classes that extend the base class
extend your subclass. Then you can advise your subclass instead. We use
this approach in the aTrack project; and I have a simplified example below.

I would like to see future AspectJ versions offer less invasive
implementation strategies for these kinds of cases (e.g., allowing
generation of "hook" methods that can be advised on classes where there's
advice on a base class that the compiler doesn't control).

Example:

public class MyStrutsAction extends Action {
    public ActionMapping execute(...) {
        return super.execute(...);
    }
}

aspect SecureExecutions {
    before() : execution(* MyStrutsAction.execute(..)) {
        // your action here
    }
}

Re: Protected ITD's, this is a topic that has come up before, and I even
submitted a bugzilla bug entry about it a while ago. The interesting
question is what should protected mean. I would expect a protected ITD
would be protected _with respect to the aspect_, e.g.,

abstract aspect SecurityPolicy {
    protected interface SecuredData {}

    protected void SecuredData.enableAccess(User user) {
        // implementation
    }
...
}

aspect AtmSecurity extends SecurityPolicy {
    ...

    after(User fromUser, User toUser) returning :
      rightsDelegation(fromUser, toUser) {
        getDataFor(fromUser).enableAccess(toUser);
    }
}

However, clearly there are cases where one would like to be able to
override a protected method with an ITD (and using advice to do it seems
like a work-around). Note that in the latest version of AspectJ you would
need a privileged aspect to invoke protected members of a target class from
within an ITD implementation.

Ron

Ron Bodkin
Chief Technology Officer
New Aspects of Software
o: (415) 824-4690
m: (415) 509-2895


> ------------Original Message------------
> From: Reid Hartenbower <reidh@xxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Sat, Oct-23-2004 2:41 PM
> Subject: [aspectj-users] protected inter-type methods
>
> Pardon if this has already been discussed, but according to the
> documentation (and the compiler), "AspectJ does not provide protected
> inter-type members."
> Why?  This works against modularity, in my case.
> I'd like to advise certain protected methods implemented in third-party
>
> classes which I have subclassed, but I only want to weave my classes,
> not the third-party jars.   Because I can't introduce protected methods
>
> to these subclasses, I believe I am forced to put stub methods in their
>
> source that invoke the super methods, and advise these stub methods
> instead.
> This is not a grotesque workaround, but inserting code in the
> subclasses
> that has meaning only to the aspect breaks the encapsulation of the
> aspect.   Or am I missing something?
>
> _______________________________________________
> 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/aspectj-users