[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Method call in a class hierarchy
|
Hi Virgil,
Unlike C, Java doesn't distinguish define and declare, so the method
is "declared" in both A and B. As shown by the program below,
- For method-execution, the declaring type of the join point signature
is the class declaring the method/code being advised
- For method-call, the declaring type of the join point signature
is the type of the reference used to make the call (regardless
of the actual type of the referent or the typepattern)
This tracks the referent of the typepattern in both execution(..)
and call(..), but in both cases a subtype matches when a supertype
is specified. (Either way, don't confuse the join point signature
with the method signature. Join point signatures are designed to
be as close as possible to the Java stuff they represent, but they
are not the same thing.)
For more information, see the signature part of the semantics guide
section on pointcuts:
http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html
and also the part titled "Matching based on the declaring type"
So: you can't *always* get the topmost declaring type A as the declaring
type of the join point. Even if you use call and A as your type pattern
-- something like call(* A.*(..)) -- if the type reference used to make
the call is B (a subtype of A), the declaring type of the call join point
signature is B.
Wes
--------------- output of java D
--- new A()
call A class A
call - class A
exec A class A
exec - class A
--- new B()
call A class B
call B class B
call - class B
exec A class B
exec B class B
exec - class B
--- new C()
call A class C
call B class C
call C class C
call - class C
exec A class B
exec B class B
exec - class B
--- ((A)new C())
call A class A
call - class A
exec A class B
exec B class B
exec - class B
--- ((B)new C())
call A class B
call B class B
call - class B
exec A class B
exec B class B
exec - class B
--------------- D.java
import org.aspectj.lang.JoinPoint;
public class D {
public static void main(String[] a) {
System.out.println("--- new A()");
new A().run();
System.out.println("--- new B()");
new B().run();
System.out.println("--- new C()");
new C().run();
System.out.println("--- ((A)new C())");
((A)new C()).run();
System.out.println("--- ((B)new C())");
((B)new C()).run();
}
}
class A { public void run() {}}
class B extends A { public void run() {}}
class C extends B { }
aspect AC {
before() : execution(void A.run()) { log("exec A", thisJoinPoint); }
before() : call(void A.run()) { log("call A", thisJoinPoint); }
before() : execution(void B.run()) { log("exec B", thisJoinPoint); }
before() : call(void B.run()) { log("call B", thisJoinPoint); }
before() : execution(void C.run()) { log("exec C", thisJoinPoint); }
before() : call(void C.run()) { log("call C", thisJoinPoint); }
before() : execution(void run()) { log("exec -", thisJoinPoint); }
before() : call(void run()) { log("call -", thisJoinPoint); }
void log(String s, JoinPoint jp) {
System.out.println(s + " " + jp.getSignature().getDeclaringType());
}
}
> ------------Original Message------------
> From: Trasca Virgil <virgil_trasca@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Fri, Mar-10-2006 8:49 AM
> Subject: [aspectj-users] Method call in a class hierarchy
>
>
>
> Hi all,
>
> again a simple question(I think).
>
> I have a class hierarcy like :
> class A base class.
> class B extends class A.
>
> I have a public method method1 which is implemented in
> the base class A.
>
> I have an object instance of class B type on which I
> call the method1 method. My problem is that with
> thisJoinPoint.getSignature().getDeclaringTypeName() I
> get as a class name the base class where the method is
> implemented (A) and I want to get B as it seems to be
> logically(because my object instance is of type B).
>
> My code is the following:
>
> public aspect TestAPI {
>
> pointcut whenMethodIsCalled(StatefullParentBean bean):
> this(bean) && execution (* *.* (..)) &&
> !within(TestAPI);
>
> pointcut topLevelCalls(StatefullParentBean
> bean):whenMethodIsCalled(bean) &&
> !cflowbelow(whenMethodIsCalled(StatefullParentBean));
>
> before(StatefullParentBean bean): topLevelCalls(bean)
> {
> ProfilerAPITrace.beforeMethodIsCalled(thisJoinPoint);
> }
>
> after(StatefullParentBean bean) : topLevelCalls(bean)
> {
> ProfilerAPITrace.afterMethodIsCalled(thisJoinPoint);
> }
> }
>
> private static String getLabel (JoinPoint point)
> {
> Signature signature = point.getSignature();
> String className = signature.getDeclaringTypeName();
>
> int idx = className.lastIndexOf('.');
> if (idx >= 0)
> {
> className = className.substring(idx + 1);
> }
> String method = point.getSignature().getName();
> return className + "." + method;
> }
>
> I suppose is an issue with my code. Thank you very
> much for your excelent support.
>
> Virgil
>
> --- aspectj-users-request@xxxxxxxxxxx wrote:
>
> > Send aspectj-users mailing list submissions to
> > aspectj-users@xxxxxxxxxxx
> >
> > To subscribe or unsubscribe via the World Wide Web,
> > visit
> >
> >
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > or, via email, send a message with subject or body
> > 'help' to
> > aspectj-users-request@xxxxxxxxxxx
> >
> > You can reach the person managing the list at
> > aspectj-users-owner@xxxxxxxxxxx
> >
> > When replying, please edit your Subject line so it
> > is more specific
> > than "Re: Contents of aspectj-users digest..."
> >
> >
> > Today's Topics:
> >
> > 1. RE: problems with loadtime weavingand
> > rmicommunication
> > (Ron Bodkin)
> >
> >
> >
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 10 Mar 2006 09:45:40 -0500
> > From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> > Subject: RE: [aspectj-users] problems with loadtime
> > weavingand
> > rmicommunication
> > To: <aspectj-users@xxxxxxxxxxx>
> > Message-ID: <00a701c64451$4db3b320$86fea8c0@Aqua>
> > Content-Type: text/plain; charset="iso-8859-2"
> >
> > I think there are valid cases where a user can know
> > that they don't want to
> > weave in a loader _for their application_, for just
> > the same reasons that we
> > have exclude clauses in an aop.xml file. This isn't
> > implying that no one
> > would ever need to weave the loader, just that for
> > my aspects, I don't need
> > to affect the types loaded by this loader.
> >
> >
> >
> > The graphs that Thilo posted were a little hard to
> > read in that the 1.5.0
> > vs. dev builds both showed memory use after just 500
> > requests and for the
> > experimental build that I made showed memory use
> > after 3000 requests.
> >
> >
> >
> > I agree that the weaver state shouldn't pin class
> > loaders, but the memory
> > that is added per proxy can be significant. I'd like
> > to dig in a bit to see
> > if I can reproduce Thilo's results to understand
> > what loader(s) are in
> > effect. Maybe a good first step is to allow another
> > trace option just to
> > trace the construction of weavers for a loader. It
> > would be nice to have a
> > means to get statistics on the weaving container too
> > (a JMX remote option
> > maybe).
> >
> >
> >
> > _____
> >
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf
> > Of Matthew Webster
> > Sent: Friday, March 10, 2006 9:32 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: RE: [aspectj-users] problems with loadtime
> > weavingand
> > rmicommunication
> >
> >
> >
> >
> > Ron,
> >
> > My point is that if we as framework providers cannot
> > robustly determine when
> > a class loader should or should not be used for
> > weaving what hope has the
> > user. Requiring them to use extensive diagnostics or
> > trial an error to set
> > options is unsatisfactory. The type of configuration
> > you suggest is a short
> > term solution for experts only.
> >
> > The weaver state should not pin the class loader; if
> > it does it's a bug. The
> > dramatic difference in the graphs between the FINAL
> > and the DEVELOPMENT
> > builds would suggest we have fixed such a bug. The
> > only official link
> > between a class loader and it's weaver is in Aj and
> > that's a WeakReference.
> >
> > 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/
> >
> > Please respond to aspectj-users@xxxxxxxxxxx
> >
> > Sent by: aspectj-users-bounces@xxxxxxxxxxx
> >
> > To: <aspectj-users@xxxxxxxxxxx>
> > cc:
> > Subject: RE: [aspectj-users] problems with
> > load time
> > weavingand rmicommunication
> >
> >
> > Hi Matthew,
> >
> > Let me look into the situation a little more. It
> > appears that in Thilo's
> > case some other lightweight ClassLoaders are being
> > allocated. My concern is
> > that we aren't going to be able to hard-code all the
> > possibilities (e.g., if
> > WebLogic or WebSphere or . have their own per object
> > loader for RMI calls or
> > for that matter dynamically generated proxies). In a
> > case like that, at
> > least there would be a possibility to improve memory
> > use by configuration.
> > It, to me, is very much like excluding by type name,
> > or indeed by putting an
> > aop.xml file in a place that's visible to a loader,
> > except that there are
> > often loaders for which an aop.xml cannot be
> > deployed in advance.
> >
> > I do agree that the weaver state should be eligible
> > for GC if the
> > ClassLoader is. However, adding even 1 MB of Weaver
> > State per remote proxy
> > (which pins its ClassLoader) is a pretty significant
> > amount of overhead!
> >
> >
> >
> >
> > _____
> >
> >
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf
> > Of Matthew Webster
> > Sent: Friday, March 10, 2006 8:19 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: RE: [aspectj-users] problems with load time
> > weavingand
> > rmicommunication
> >
> >
> > Ron,
> >
> > The fix to
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=120473
> > ensured that
> > delegating class loaders were not used for weaving.
> > If the class loaders in
> > question fall into this category then they should
> > also be excluded; not by
> > name but using some other robust mechanism.
> > Suggesting configuration implies
> > a user may wish to weave on some occasions but not
> > others. How would they
> > make this decision? How would they know the name of
> > the class loader to
> > supply to the configuration? If we can't answer
> > these questions then
> > providing such an option will just confuse the user.
> >
> >
> > It would seem that these class loaders are short
> > lived; if not the JVM would
> > go OutOfMemory eventually without the help of LTW.
> > Looking at the graphs it
> > would seem that the first solution to this problem.
> > releasing any references
> >
> === message truncated ===
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
