Thank you Adrian for your long answer. I find it very useful. Thank you
to Paolo too for that links, I'll see them.
If I understand the idea is to mix three ingredients: load-time
weaving, classloader recycling and a set of aspectJ patterns (or an
aspectJ framework). The idea of making a framework for dynamic aspects
seems very atractive. We can combine adviceChain and if(enabled). The
problem I see is around advice but I suppose it will be a workaround.
These techniques solves the use case I can imagine now. Perhaps in the
future I'd think about other usecases that cannot be implemented in
this way. For now it seems enough. I'm more worried about performance
of the if (..) pointcut and for classloader recycling and weaving. Is
there any benchmark on this? Has somebody measured the performance
impact?
Thanks.
Enrique J. Amodeo Rubio.
Adrian Colyer wrote:
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
|