[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Method call in a class hierarchy


Virgil,

Some confusion my lie with fact that "thisJoinPoint.getSignature()" is equivalent to "thisJoinPointStaticPart.getSignature()" so it is static information that you are getting. The other thing to remember is that if you were to override the method in B and advise both join points you would want to know which one was being advised. You have already solved your problem by obtaining the currently executing object using "this()" whose type information you can obtain.

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:        [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