[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Incremental and runtime weaving support ?
|
Can I nominate a summary of this thread for inclusion in the FAQ? I think many users are under the mistaken impression that AspectJ provides poor support for dynamically changing aspect configuration and the solutions offered in this thread could help clear up these misconceptions.
Cheers,
Nick
On Mar 31, 2004, at 8:11 AM, Adrian Colyer wrote:
<x-tad-smaller>> I'm worried (again) about performance. Is thisJoinPoint a </x-tad-smaller>
<x-tad-smaller> > performance bottleneck? Implementing Ron's proposal would be a bad </x-tad-smaller>
<x-tad-smaller> > idea from a performance point of view? If so a lazy loading strategy</x-tad-smaller>
<x-tad-smaller> > would be useful to populate thisJoinPoint.</x-tad-smaller>
Jim and Erik had a paper at the AOSD conference that discussed the performance of if(enabled) (it's pretty good) - see http://hugunin.net/papers/aosd-2004-cameraReady.pdf.
AspectJ 1.2 also has a new option -XlazyTjp (guess what that does ;) ) which makes the performance much much better in the cases where advice uses the non-static portions of thisJoinPoint.
On the point of changing a service implementation, the following sample code shows a neat way to do this using proceed (it implements a per-instance delegate, other variations on the theme may not need this level of complexity).
/**
* @author colyer
* Runtime delegation configured on a per-instance
* basis.
*/
public class SimpleDelegationExample {
interface ICanDoIt {
void doIt();
}
static class CanDoIt implements ICanDoIt {
private String msg;
public CanDoIt(String s) {
this.msg = s;
}
public void doIt() {
System.out.println(msg);
}
}
public static void main(String[] args) {
ICanDoIt a = new CanDoIt("I can do it");
ICanDoIt b = new CanDoIt("You can do it too");
a.doIt();
b.doIt();
ICanDoIt c = new CanDoIt("We really should do this more often");
// try running this program with and without the next two lines commented out to observe the difference
DelegationMgr mgrForA = DelegationMgr.aspectOf(a);
mgrForA.setDelegate(c);
a.doIt();
}
private static aspect DelegationMgr pertarget(canDo()){
private ICanDoIt delegate;
public void setDelegate(ICanDoIt delegate) {
this.delegate = delegate;
}
pointcut delegationScope(ICanDoIt delegate) :
execution(* ICanDoIt.*(..)) && this(delegate);
Object around(ICanDoIt d) : delegationScope(d) {
return proceed(delegate != null ? delegate : d);
}
}
}
-- Adrian
Adrian_Colyer@xxxxxxxxxx
<x-tad-smaller>aspectj-users-admin@xxxxxxxxxxx wrote on 31/03/2004 15:46:51:</x-tad-smaller>
<x-tad-smaller> > Hi again, I have just read your email Ron and I see that around</x-tad-smaller>
<x-tad-smaller> > advice is tricky. I like your proposed solution. I don't think it is</x-tad-smaller>
<x-tad-smaller> > complex. It is coherent. If you have a pointcut that intercepts </x-tad-smaller>
<x-tad-smaller> > advice execution then thisJoinPoint must have information about the </x-tad-smaller>
<x-tad-smaller> > intercepted advice. It seems coherent to me. Under my point of view </x-tad-smaller>
<x-tad-smaller> > if we put another pointcut in the language (like adviceexecution)</x-tad-smaller>
<x-tad-smaller> > then we must update thisJoinPoint API to be able to retrieve </x-tad-smaller>
<x-tad-smaller> > information about it. ThisJoinPoint must be equal useful for all the</x-tad-smaller>
<x-tad-smaller> > joinPoints.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > I'm worried (again) about performance. Is thisJoinPoint a </x-tad-smaller>
<x-tad-smaller> > performance bottleneck? Implementing Ron's proposal would be a bad </x-tad-smaller>
<x-tad-smaller> > idea from a performance point of view? If so a lazy loading strategy</x-tad-smaller>
<x-tad-smaller> > would be useful to populate thisJoinPoint.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > An use case for dynamic aspects. Suppose I want to build an </x-tad-smaller>
<x-tad-smaller> > application server that offers several crosscutting services </x-tad-smaller>
<x-tad-smaller> > (security, logging, performace metrics, etc.). It seems that AspectJ</x-tad-smaller>
<x-tad-smaller> > is a good technology to do this. But if I want to be able to </x-tad-smaller>
<x-tad-smaller> > stop/start this services (potentially implemented with around</x-tad-smaller>
<x-tad-smaller> > advice) or change service implementation with a custom one (this </x-tad-smaller>
<x-tad-smaller> > could be done with chain advice). It is very interesting to be able</x-tad-smaller>
<x-tad-smaller> > to "deploy pointcuts" that match my own code. Example of this. The </x-tad-smaller>
<x-tad-smaller> > application server expose a trace service with the following "interface":</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public abstract aspect TraceService implements DynamicAspect</x-tad-smaller>
<x-tad-smaller> > {</x-tad-smaller>
<x-tad-smaller> > abstract pointcut enterMethod(String methodName);</x-tad-smaller>
<x-tad-smaller> > abstract pointcut exitMethod(String methodName);</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > // Follows advice that could use a chain advice pattern</x-tad-smaller>
<x-tad-smaller> > ...</x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > I want customize the trace service for my own servlets and EJBs but </x-tad-smaller>
<x-tad-smaller> > I don't want to touch any line of my code so I write the following aspect:</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public aspect MyTraceService extends TraceService</x-tad-smaller>
<x-tad-smaller> > {</x-tad-smaller>
<x-tad-smaller> > /* MyTraceService only traces exactly what the programmer wants. */</x-tad-smaller>
<x-tad-smaller> > pointcut enterMethod(String methodName): /* specific pointcuts </x-tad-smaller>
<x-tad-smaller> > of my code that I'm interested to trace */;</x-tad-smaller>
<x-tad-smaller> > pointcut exitMethod(String methodName):/* specific pointcuts of </x-tad-smaller>
<x-tad-smaller> > my code that I'm interested to trace */;</x-tad-smaller>
<x-tad-smaller> > }</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > And I'd like to deploy (or activate/desactivate) this aspect. This </x-tad-smaller>
<x-tad-smaller> > style of programming have some advantages: it's simple for the </x-tad-smaller>
<x-tad-smaller> > application programmer (not the application server programmer) and </x-tad-smaller>
<x-tad-smaller> > decouples application code from application server (it encapsulates</x-tad-smaller>
<x-tad-smaller> > dependencies in MyTraceService). Perhaps someone knows another way</x-tad-smaller>
<x-tad-smaller> > of doing this.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Of course it should be perfect if I could have activated several </x-tad-smaller>
<x-tad-smaller> > trace services, one per each application or J2EE module, at the same time.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > I know that these are advanced topics and not everyday programming</x-tad-smaller>
<x-tad-smaller> > but I think they are important if we want AspectJ to be used to </x-tad-smaller>
<x-tad-smaller> > build servers, containers and frameworks.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Thanks for your patience :-)</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Enrique J. Amodeo Rubio</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Ron Bodkin wrote:</x-tad-smaller>
<x-tad-smaller>> Indeed, enabling or disabling an aspect is a crosscutting concern. </x-tad-smaller>
<x-tad-smaller> > You can *almost* write a general-purpose aspect that allows you to </x-tad-smaller>
<x-tad-smaller> > dynamically enable or disable other aspects. It's easy to do this </x-tad-smaller>
<x-tad-smaller> > for arbitrary before or after advice, but the problem arises if </x-tad-smaller>
<x-tad-smaller> > you'd like to disable around advice. If you don't proceed with </x-tad-smaller>
<x-tad-smaller> > around advice, it skips the original method... I've included an</x-tad-smaller>
<x-tad-smaller> > example aspect below that works if your dynamic aspects don't use </x-tad-smaller>
<x-tad-smaller> > around advice. </x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> We could generalize AspectJ a little bit to allow this aspect to </x-tad-smaller>
<x-tad-smaller> > enable and disable around advice too: we could make proceed a </x-tad-smaller>
<x-tad-smaller> > closure on JoinPoint and add some additional context to JoinPoint </x-tad-smaller>
<x-tad-smaller> > for advice execution: a field advisedJoinPoint. Then we could </x-tad-smaller>
<x-tad-smaller> > disable around advice with: thisJoinPoint.getAdvisedJoinPoint.</x-tad-smaller>
<x-tad-smaller> > getProceed().run(args)</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> It would also be nice if target for adviceexecution were bound to </x-tad-smaller>
<x-tad-smaller> > the currently running object (this) at the advised join point. The </x-tad-smaller>
<x-tad-smaller> > main question in my mind is whether there are compelling use cases </x-tad-smaller>
<x-tad-smaller> > to justify the extra complexity of this idea.</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> /**</x-tad-smaller>
<x-tad-smaller> > * This aspect automates enabling and disabling of other aspects at runtime</x-tad-smaller>
<x-tad-smaller> > * Any aspect that implements the marker interface DynamicAspect will be </x-tad-smaller>
<x-tad-smaller> > * able to be enabled or disabled dynamically at runtime.</x-tad-smaller>
<x-tad-smaller> > *</x-tad-smaller>
<x-tad-smaller> > * It's also easy to use this style of code to support configuring the aspect </x-tad-smaller>
<x-tad-smaller> > * on a per-instance basis: keep a set of deployed objects, and check if</x-tad-smaller>
<x-tad-smaller> > * this is in the set of deployed objects...</x-tad-smaller>
<x-tad-smaller> > * </x-tad-smaller>
<x-tad-smaller> > */</x-tad-smaller>
<x-tad-smaller> > public aspect AspectManagement {</x-tad-smaller>
<x-tad-smaller> > private boolean DynamicAspect.enabled;</x-tad-smaller>
<x-tad-smaller>> public DynamicAspect.setEnabled(boolean enabled) {</x-tad-smaller>
<x-tad-smaller> > this.enabled = enabled;</x-tad-smaller>
<x-tad-smaller> > }</x-tad-smaller>
<x-tad-smaller>> around() : adviceexecution() && within(DynamicAspect+) {</x-tad-smaller>
<x-tad-smaller>> // could check for around advice by looking at the generated</x-tad-smaller>
<x-tad-smaller> > name in the signature</x-tad-smaller>
<x-tad-smaller> > if (enabled) {</x-tad-smaller>
<x-tad-smaller> > proceed();</x-tad-smaller>
<x-tad-smaller> > }</x-tad-smaller>
<x-tad-smaller> > }</x-tad-smaller>
<x-tad-smaller>> // can expose DynamicAspect for JMX...</x-tad-smaller>
<x-tad-smaller>> /**</x-tad-smaller>
<x-tad-smaller> > * This advice makes it an error to call any method on a disabled aspect.</x-tad-smaller>
<x-tad-smaller> > */</x-tad-smaller>
<x-tad-smaller> > around() : (execution(* *(..)) || execution(* new(..))) && </x-tad-smaller>
<x-tad-smaller> > within(DynamicAspect+) {</x-tad-smaller>
<x-tad-smaller> > if (enabled) {</x-tad-smaller>
<x-tad-smaller> > proceed();</x-tad-smaller>
<x-tad-smaller> > } else {</x-tad-smaller>
<x-tad-smaller> > throw new UnsupportedOperationException("calling a </x-tad-smaller>
<x-tad-smaller> > method on a disabled aspect.");</x-tad-smaller>
<x-tad-smaller> > }</x-tad-smaller>
<x-tad-smaller>> }</x-tad-smaller>
<x-tad-smaller>> }</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> Ron Bodkin</x-tad-smaller>
<x-tad-smaller>> Chief Technology Officer</x-tad-smaller>
<x-tad-smaller>> New Aspects of Software</x-tad-smaller>
<x-tad-smaller>> o: (415) 824-4690</x-tad-smaller>
<x-tad-smaller>> m: (415) 509-2895</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> ------------Original Message------------</x-tad-smaller>
<x-tad-smaller>> From: Adrian Colyer <adrian_colyer@xxxxxxxxxx></x-tad-smaller>
<x-tad-smaller>> To: aspectj-users@xxxxxxxxxxx</x-tad-smaller>
<x-tad-smaller>> Date: Wed, Mar-31-2004 4:20 AM</x-tad-smaller>
<x-tad-smaller>> Subject: Re: [aspectj-users] Incremental and runtime weaving support ?</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller> > Forgive the long answer, but I think it is worth discussing some of </x-tad-smaller>
<x-tad-smaller> > the options here, since many people are unaware of what AspectJ can</x-tad-smaller>
<x-tad-smaller> > do in this regard. </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > First of all, AspectJ has been able to support *load-time* weaving </x-tad-smaller>
<x-tad-smaller> > since the 1.1 release, and several folks have written weaving </x-tad-smaller>
<x-tad-smaller> > classloaders that exploited that fact. What we didn't do, was make </x-tad-smaller>
<x-tad-smaller> > it especially easy to exploit those load-time weaving capabilities.</x-tad-smaller>
<x-tad-smaller> > AspectJ 1.2 will ship with a new sample script in the examples </x-tad-smaller>
<x-tad-smaller> > directory, "aj"that will launch any Java application using load-time</x-tad-smaller>
<x-tad-smaller> > weaving of aspects from the ASPECTPATH environment variable ("aj" is</x-tad-smaller>
<x-tad-smaller> > to "ajc" as "java" is to "javac"). In addition, there is a weaving </x-tad-smaller>
<x-tad-smaller> > class loader shipped in the tools jar, and an adaptor that makes it </x-tad-smaller>
<x-tad-smaller> > easy to plug load-time weaving into an existing class-loader </x-tad-smaller>
<x-tad-smaller> > hierarchy. You can get many of the same benefits of arbitrary run-</x-tad-smaller>
<x-tad-smaller> > time weaving by combining load-time weaving with class recycling -</x-tad-smaller>
<x-tad-smaller> > and indeed most middleware systems support application re-loading to</x-tad-smaller>
<x-tad-smaller> > pick up changes at runtime by using custom classloaders.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Whether you weave at load-time or before, there are also a bunch of </x-tad-smaller>
<x-tad-smaller> > things you can do with aspects that give you a high degree of </x-tad-smaller>
<x-tad-smaller> > runtime dynamicity:</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Simplest of all is the aspect that can be turned on or off at </x-tad-smaller>
<x-tad-smaller> > runtime - this can be made very efficient indeed following the pattern</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public aspect DoSomethingInteresting { </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > private static boolean isEnabled = false; </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public static void setEnabled(boolean turnMeOn) {</x-tad-smaller>
<x-tad-smaller> > this.isEnabled = turnMeOn;</x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > pointcut isEnabled() : if(isEnabled);</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > // regular advice goes here, e.g. </x-tad-smaller>
<x-tad-smaller> > before() : someInterestingJoinPoint() && isEnabled() { </x-tad-smaller>
<x-tad-smaller> > // here we go... </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > You can then enable or disable the aspect behavior at runtime using </x-tad-smaller>
<x-tad-smaller> > the following snippet: </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > DoSomethingInteresting.setEnabled(true);</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > You can follow the same basic pattern for aspects that are </x-tad-smaller>
<x-tad-smaller> > pertarget, percflow etc. by making the isEnabled and setEnabled </x-tad-smaller>
<x-tad-smaller> > members non-static, and using </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > DoSomethingInteresting.aspectOf(x).setEnabled(true);</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Using the per-clauses you can also easily get a whole additional </x-tad-smaller>
<x-tad-smaller> > range of runtime behaviours, for example the following aspect lets</x-tad-smaller>
<x-tad-smaller> > you decide on a pertarget basis whether or not the aspect behaviour </x-tad-smaller>
<x-tad-smaller> > should be enabled (strictly, whether an aspect instance should be created). </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public aspect DoSomethingElseInteresting</x-tad-smaller>
<x-tad-smaller> > pertarget(candidateTargetObject(Object)) { </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > private static boolean enableBehaviourFor(Object o) { </x-tad-smaller>
<x-tad-smaller> > // some runtime test </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > pointcut candidateTargetObject(Object o) : someCalls() && </x-tad-smaller>
<x-tad-smaller> > target(o) && if(enableBehaviourFor(o));</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > // advice etc. goes here. </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > You could imagine a similar aspect using percflow and deciding on an</x-tad-smaller>
<x-tad-smaller> > individual control flow basis whether to create an aspect instance or not. </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Frameworks like the JBoss AOP framework only allow you to do true </x-tad-smaller>
<x-tad-smaller> > runtime weaving on classes that have been pre-prepared (at load-time</x-tad-smaller>
<x-tad-smaller> > or before) to instrument their join points (I can't speak for </x-tad-smaller>
<x-tad-smaller> > AspectWerkz and Prose off the top of my head). If you can accept the</x-tad-smaller>
<x-tad-smaller> > pre-preparation step, then AspectJ can give you an equivalent degree</x-tad-smaller>
<x-tad-smaller> > of runtime flexibility using a pattern like the following: </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public aspect RuntimeAdviceChainExample { </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > private ICommand[] adviceChain;</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > public void setAdviceChain(ICommand[] adviceChain) { </x-tad-smaller>
<x-tad-smaller> > this.adviceChain = adviceChain;</x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > // could imagine other methods that let me add, remove, reorder </x-tad-smaller>
<x-tad-smaller> > commands in the advice chain, omitted for brevity </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > pointcut someInterestingJoinPoints() : ..... ; </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > before() : someInterestingJoinPoints() { </x-tad-smaller>
<x-tad-smaller> > for (int i = 0; i < adviceChain.length; i++) { </x-tad-smaller>
<x-tad-smaller> > adviceChain[i].execute(thisJoinPoint);</x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > I've shown a general form of the aspect - if you have known context </x-tad-smaller>
<x-tad-smaller> > at the set of join points of interest, and are prepared to make a </x-tad-smaller>
<x-tad-smaller> > custom command interface you can write more efficient advice, e.g. </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > after(BankAccount acc) returning : bankOperation(acc) { </x-tad-smaller>
<x-tad-smaller> > for (int i = 0; i < adviceChain.length; i++) { </x-tad-smaller>
<x-tad-smaller> > adviceChain[i].execute(acc);</x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > } </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > So, to summarize, you can already do a surprising amount at runtime </x-tad-smaller>
<x-tad-smaller> > using the existing facilities of AspectJ. Are there any strong use </x-tad-smaller>
<x-tad-smaller> > cases out there not supported by one of the above mechanisms?</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > -- Adrian</x-tad-smaller>
<x-tad-smaller> > Adrian_Colyer@xxxxxxxxxx</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > aspectj-users-admin@xxxxxxxxxxx wrote on 31/03/2004 11:59:27:</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > > Hi,</x-tad-smaller>
<x-tad-smaller> > > you can try dynamic AOP tools, like:</x-tad-smaller>
<x-tad-smaller> > > PROSE (http://prose.ethz.ch/)</x-tad-smaller>
<x-tad-smaller> > > Aspectwerkz (http://aspectwerkz.codehaus.org/)</x-tad-smaller>
<x-tad-smaller> > > JBoss/AOP</x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > cheers</x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > paolo</x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > On Wed, 31 Mar 2004 12:26:13 +0200, Enrique J. Amodeo Rubio </x-tad-smaller>
<x-tad-smaller> > > <eamodeorubio@xxxxxxxxxxxxxx> wrote:</x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > > Hi everybody,</x-tad-smaller>
<x-tad-smaller> > > ></x-tad-smaller>
<x-tad-smaller> > > > I had a talk with my boss about the limits of AspectJ and some </x-tad-smaller>
<x-tad-smaller> > > questions appeared.</x-tad-smaller>
<x-tad-smaller> > > > Is there any plans about supporting runtime (not load time) </x-tad-smaller>
<x-tad-smaller> > > weaving? And for incremental weaving? I have read about -Xreweavable</x-tad-smaller>
<x-tad-smaller> > > and I wonder if this option could made feasible to support these </x-tad-smaller>
<x-tad-smaller> > > features in the future. For runtime weaving I mean the ability to </x-tad-smaller>
<x-tad-smaller> > > load and weave an aspect during the execution of a program in a </x-tad-smaller>
<x-tad-smaller> > > similar way that you can load a class and use them. I think that </x-tad-smaller>
<x-tad-smaller> > > incremental weaving is necessary in order to achieve a good </x-tad-smaller>
<x-tad-smaller> > > performance. Of course some AspectJ features like introduction could</x-tad-smaller>
<x-tad-smaller> > > not support this (but I can live without them). I understand that </x-tad-smaller>
<x-tad-smaller> > > JVM technology can put limitations on these topics.</x-tad-smaller>
<x-tad-smaller> > > ></x-tad-smaller>
<x-tad-smaller> > > > Perhaps this subject has been discussed in another mail threads. </x-tad-smaller>
<x-tad-smaller> > > If so please send me some links since I can't find them.</x-tad-smaller>
<x-tad-smaller> > > ></x-tad-smaller>
<x-tad-smaller> > > > Thanks,</x-tad-smaller>
<x-tad-smaller> > > ></x-tad-smaller>
<x-tad-smaller> > > > Enrique J. Amodeo Rubio</x-tad-smaller>
<x-tad-smaller> > > > _______________________________________________</x-tad-smaller>
<x-tad-smaller> > > > aspectj-users mailing list</x-tad-smaller>
<x-tad-smaller> > > > aspectj-users@xxxxxxxxxxx</x-tad-smaller>
<x-tad-smaller> > > > http://dev.eclipse.org/mailman/listinfo/aspectj-users</x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > </x-tad-smaller>
<x-tad-smaller> > > _______________________________________________</x-tad-smaller>
<x-tad-smaller> > > aspectj-users mailing list</x-tad-smaller>
<x-tad-smaller> > > aspectj-users@xxxxxxxxxxx</x-tad-smaller>
<x-tad-smaller> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users</x-tad-smaller>
