Indeed, enabling or disabling an aspect is a crosscutting concern.
You can *almost* write a general-purpose aspect that allows you to
dynamically enable or disable other aspects. It's easy to do this for
arbitrary before or after advice, but the problem arises if you'd like
to disable around advice. If you don't proceed with around advice, it
skips the original method... I've included an example aspect below that
works if your dynamic aspects don't use around advice.
We could generalize AspectJ a little bit to allow this aspect to
enable and disable around advice too: we could make proceed a closure
on JoinPoint and add some additional context to JoinPoint for advice
execution: a field advisedJoinPoint. Then we could disable around
advice with: thisJoinPoint.getAdvisedJoinPoint.getProceed().run(args)
It would also be nice if target for adviceexecution were bound to
the currently running object (this) at the advised join point. The
main question in my mind is whether there are compelling use cases to
justify the extra complexity of this idea.
/**
* This aspect automates enabling and disabling of other aspects at
runtime
* Any aspect that implements the marker interface DynamicAspect will
be
* able to be enabled or disabled dynamically at runtime.
*
* It's also easy to use this style of code to support configuring the
aspect
* on a per-instance basis: keep a set of deployed objects, and check if
* this is in the set of deployed objects...
*
*/
public aspect AspectManagement {
private boolean DynamicAspect.enabled;
public DynamicAspect.setEnabled(boolean enabled) {
this.enabled = enabled;
}
around() : adviceexecution() && within(DynamicAspect+)
{
// could check for around advice by looking at the
generated name in the signature
if (enabled) {
proceed();
}
}
// can expose DynamicAspect for JMX...
/**
* This advice makes it an error to call any method on a disabled
aspect.
*/
around() : (execution(* *(..)) || execution(* new(..)))
&& within(DynamicAspect+) {
if (enabled) {
proceed();
} else {
throw new UnsupportedOperationException("calling a
method on a disabled aspect.");
}
}
}
Ron Bodkin
Chief Technology Officer
New Aspects of Software
o: (415) 824-4690
m: (415) 509-2895
------------Original Message------------
From: Adrian Colyer <adrian_colyer@xxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Wed, Mar-31-2004 4:20 AM
Subject: Re: [aspectj-users] Incremental and runtime weaving
support ?
Forgive the long answer, but I
think it is worth discussing some of the options here, since many
people are unaware of what AspectJ can do in this regard.
First of all, AspectJ has been
able to support *load-time* weaving since the 1.1 release, and several
folks have written weaving classloaders that exploited that fact. What
we didn't do, was make it especially easy to exploit those load-time
weaving capabilities. AspectJ 1.2 will ship with a new sample script in
the examples directory, "aj"that will launch any Java application using
load-time weaving of aspects from the ASPECTPATH environment variable
("aj" is to "ajc" as "java" is to "javac"). In addition, there is a
weaving class loader shipped in the tools jar, and an adaptor that
makes it easy to plug load-time weaving into an existing class-loader
hierarchy. You can get many of the same benefits of arbitrary run-time
weaving by combining load-time weaving with class recycling - and
indeed most middleware systems support application re-loading to pick
up changes at runtime by using custom classloaders.
Whether you weave at load-time or
before, there are also a bunch of things you can do with aspects that
give you a high degree of runtime dynamicity:
Simplest of all is the aspect that
can be turned on or off at runtime - this can be made very efficient
indeed following the pattern
public aspect
DoSomethingInteresting {
private static boolean isEnabled
= false;
public static void
setEnabled(boolean turnMeOn) {
this.isEnabled = turnMeOn;
}
pointcut isEnabled() :
if(isEnabled);
// regular advice goes here, e.g.
before() :
someInterestingJoinPoint() && isEnabled() {
// here we go...
}
}
You can then enable or disable the
aspect behavior at runtime using the following snippet:
DoSomethingInteresting.setEnabled(true);
You can follow the same basic
pattern for aspects that are pertarget, percflow etc. by making the
isEnabled and setEnabled members non-static, and using
DoSomethingInteresting.aspectOf(x).setEnabled(true);
Using the per-clauses you can also
easily get a whole additional range of runtime behaviours, for example
the following aspect lets you decide on a pertarget basis whether or
not the aspect behaviour should be enabled (strictly, whether an aspect
instance should be created).
public aspect
DoSomethingElseInteresting pertarget(candidateTargetObject(Object)) {
private static boolean
enableBehaviourFor(Object o) {
// some runtime test
}
pointcut
candidateTargetObject(Object o) : someCalls() && target(o)
&& if(enableBehaviourFor(o));
// advice etc. goes here.
}
You could imagine a similar aspect
using percflow and deciding on an individual control flow basis whether
to create an aspect instance or not.
Frameworks like the JBoss AOP
framework only allow you to do true runtime weaving on classes that
have been pre-prepared (at load-time or before) to instrument their
join points (I can't speak for AspectWerkz and Prose off the top of my
head). If you can accept the pre-preparation step, then AspectJ can
give you an equivalent degree of runtime flexibility using a pattern
like the following:
public aspect
RuntimeAdviceChainExample {
private ICommand[] adviceChain;
public void
setAdviceChain(ICommand[] adviceChain) {
this.adviceChain =
adviceChain;
}
// could imagine other methods
that let me add, remove, reorder commands in the advice chain, omitted
for brevity
pointcut
someInterestingJoinPoints() : ..... ;
before() :
someInterestingJoinPoints() {
for (int i = 0; i <
adviceChain.length; i++) {
adviceChain[i].execute(thisJoinPoint);
}
}
}
I've shown a general form of the
aspect - if you have known context at the set of join points of
interest, and are prepared to make a custom command interface you can
write more efficient advice, e.g.
after(BankAccount acc) returning :
bankOperation(acc) {
for (int i = 0; i <
adviceChain.length; i++) {
adviceChain[i].execute(acc);
}
}
So, to summarize, you can already
do a surprising amount at runtime using the existing facilities of
AspectJ. Are there any strong use cases out there not supported by one
of the above mechanisms?
-- Adrian
Adrian_Colyer@xxxxxxxxxx
aspectj-users-admin@xxxxxxxxxxx wrote on
31/03/2004 11:59:27:
> Hi,
> you can try dynamic AOP tools, like:
> PROSE (http://prose.ethz.ch/)
> Aspectwerkz (http://aspectwerkz.codehaus.org/)
> JBoss/AOP
>
> cheers
>
> paolo
>
>
> On Wed, 31 Mar 2004 12:26:13 +0200, Enrique J. Amodeo Rubio
> <eamodeorubio@xxxxxxxxxxxxxx> wrote:
>
> > Hi everybody,
> >
> > I had a talk with my boss about the limits of AspectJ and
some
> questions appeared.
> > Is there any plans about supporting runtime (not load time)
> weaving? And for incremental weaving? I have read about
-Xreweavable
> and I wonder if this option could made feasible to support these
> features in the future. For runtime weaving I mean the ability to
> load and weave an aspect during the execution of a program in a
> similar way that you can load a class and use them. I think that
> incremental weaving is necessary in order to achieve a good
> performance. Of course some AspectJ features like introduction
could
> not support this (but I can live without them). I understand that
> JVM technology can put limitations on these topics.
> >
> > Perhaps this subject has been discussed in another mail
threads.
> If so please send me some links since I can't find them.
> >
> > Thanks,
> >
> > Enrique J. Amodeo Rubio
> > _______________________________________________
> > 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
