| Re: [aspectj-users] Incremental and runtime weaving support ? |
<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>