[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[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 ===
