[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Overriding pointcuts
|
Savita,
So you have a number of options:
If you can use LTW and have occasions
where a flight recorder is not needed at all then don't compile-time weave
it. Rather than use LTW to undo something done earlier simply use it to
enable the feature when needed. This is one of the primary use cases for
LTW.
Alternatively you can use aop.xml to
enable/disable LTW for the whole system, enable/disable the weaving of
the flight recorder (you may have other aspects that you need) or control
the scope of the weave though concrete aspects defined in aop.xml.
Finally you can use runtime enablement,
possibly in combination with the other options, which when implemented
using the "if()" pointcut dramatically reduces the overhead of
AspectJ and the flight recorder. While we must still create the StaticJoinPoint
objects (used by thisJoinPoint/thisJoinPointStaticPart to provide method
name e.t.c) during class initialization, the JoinPoint objects (which give
access to dynamic information like method arguments) are created lazily
only when the flight recorder is enabled. The overhead of your aspect itself
is limited to static initialization and of course the, hopefully very efficient,
enablement test.
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/
"Wes" <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx
06/09/2006 19:35
Please respond to
wes@xxxxxxxxxxxxxx; Please respond to
aspectj-users@xxxxxxxxxxx |
|
To
| aspectj-users@xxxxxxxxxxx
|
cc
|
|
Subject
| RE: [aspectj-users] Overriding pointcuts |
|
Hi Savita -
If you'd like the deployer of aop.xml to
be able to enable or disable the flight recorder entirely
when the application is loaded, declare the
aspect abstract, and then have the deployer declare
a concrete subaspect in aop.xml if s/he wants
it enabled.
That's different from making the pointcut
fail at runtime by relying on a boolean flag. The flag
is preferable where you want to enable and
disable the flight recorder while the program is
running, as Ron suggested with JMX. Ron's
correct to point out that JoinPoint, the reflective
representation of a join point available
in the body of advice, has of late become constructed
lazily (by default, I believe), so you can
avoid that overhead if there is no other advice on that
join point. But I believe the runtime
still needs to setup for evaluating the join point and advice
and do the test (but this should be minimal
-- certainly as efficient as hand-coding).
Wes
------------Original Message------------
From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Wed, Sep-6-2006 10:56 AM
Subject: RE: [aspectj-users] Overriding pointcuts
Savita you can significantly
reduce the overhead by dynamically enabling and disabling your aspects.
This can be as simple as using the if pointcut like so
public aspect FlightRecorder {
private static boolean
enabled; // can be controlled through JMX, for example
public pointcut flightMethod():
execution(!@PrimitiveDataLoggerAnnotation
public * *.Method*(..));
private pointcut recordedMethod():
if(enabled) && flightMethod();
before() : recordedMethod() { … }
after() : recordedMethod()
{ … }
}
AspectJ constructs join points
lazily when they are guarded like this, so you should see the runtime overhead
as simply the time for a single (inlined) if test. This is often desirable,
especially if you would like to be able to enable and disable recording
at runtime. You can also allow more dynamic scoping e.g., by package and
class like with logging frameworks, possibly also with a global enabled
switch. AspectJ been tuned significantly over the years to support efficiently
running when aspects like this are disabled, but certainly you should benchmark
the overhead in your case.
Ron
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan,
Savita
Sent: Wednesday, September 06, 2006 10:22 AM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Overriding pointcuts
Mathew,
Thanks for your response. That's
a bummer. Lets look at the problem from a different vantage point.
What Iam trying to accomplish
here is turn off the flight recorder logging with some configuration, without
recompiling. I can do this by turning it off in the flight recorder, but
then I will be taking the hit of AspectJ framework ( creating JoinPoints
etc), which I dont want.
Rephrasing the question, Is it
possible to turnoff AspectJ framework in the code without recompiling,
by an off/on switch?
Thanks,
Savita
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matthew
Webster
Sent: Wednesday, September 06, 2006 3:18 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Overriding pointcuts
Savita,
Unfortunately this won't work because you can only extend abstract aspects
so you cannot override the behaviour of an existing woven concrete aspect.
You can override a pointcut but only in a sub-aspect:
public abstract
aspect
AbstractPrimitiveFlightRecorder {
protected
pointcut
myMethod() :
PrimitiveFlightRecorderPointcutLibrary.recordedMethod();
}
public aspect
PrimitiveFlightRecorderAspect extends
AbstractPrimitiveFlightRecorder
{
protected
pointcut
myMethod()
: execution(!@PrimitiveDataLoggerAnnotation
public
* *.Method*(..));
before
(): myMethod() {
System.out.println(">
PrimitiveFlightRecorderAspect.before() "
+ thisJoinPoint);
}
after
(): myMethod() {
System.out.println("<
PrimitiveFlightRecorderAspect.before() "
+ thisJoinPoint);
}
}
However one solution is to use a separate pointcut library which is used
to weave at compile-time:
public aspect
PrimitiveFlightRecorderPointcutLibrary {
protected
pointcut
recordedMethod() :
execution(@PrimitiveDataLoggerAnnotation
public
* *.Method*(..));
}
public aspect
PrimitiveFlightRecorderAspect
{
protected
pointcut
myMethod() :
PrimitiveFlightRecorderPointcutLibrary.recordedMethod();
before
(): myMethod() {
System.out.println(">
PrimitiveFlightRecorderAspect.before() "
+ thisJoinPoint);
}
after
(): myMethod() {
System.out.println("<
PrimitiveFlightRecorderAspect.before() "
+ thisJoinPoint);
}
}
Then for LTW substitute an alternative implementation of the library. Because
_all_ aspects must be woven, including those woven previously, you will
pick up the new pointcut definition. Unfortunately you cannot define pointcut
libraries using XML.
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/[1]
"Chandan, Savita"
<Savita.Chandan@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx
06/09/2006 02:43
Please respond to
aspectj-users@xxxxxxxxxxx |
|
To
| <aspectj-users@xxxxxxxxxxx>
|
cc
|
|
Subject
| [aspectj-users] Overriding pointcuts |
|
Hi,
I want to override pointcuts inserted in the
aspect code during compile, at run time. What would I do to achieve this?
If I created a pointcut in aop.xml that contradicts the pointcut inserted
in the code, what would happen?
For ex.
In my aspect class
public aspect PrimitiveFlightRecorderAspect
{
pointcut myMethod(): execution(@ PrimitiveDataLoggerAnnotation
public * *.Method*(..)) );
before
(): myMethod() {
}
after
(): myMethod() {}
}
Now if in the aop.xml if I were to do this.
(pardon me for any mistakes in the aop.xml, this is the first time I creating
one) what would happen?
<aspectj>
<aspects>
<aspect name="PrimitiveFlightRecorderAspect"/>
pointcut myMethod():
execution(! @ PrimitiveDataLoggerAnnotation public * *.Method*(..))
);
</aspects>
</aspectj>
Thanks,
Savita _______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users