I think only PER_INSTANCE aspects are created on-demand. The whole Aspect container for PER_VM, PER_CLASS, and PER_INSTANCE would have to be switched to get Aspect instances on demand. I do not want to add this overhead to the system. SO, I think an entire binding redeploy would be needed. I'll need to go back and look at the code.
Actually I do recreate the AdviceBinding. Basically,
0. I first update the AspectDefinition in AspectManager. In the chain of invocations, AspectDefinition.clearAdvisors() is called and that basically does
public void clearAdvisors()
for (Iterator it = advisors.iterator(); it.hasNext();)
String advisorName = (String) it.next();
Advisor advisor = AspectManager.instance().getAdvisor(advisorName);
if (advisor != null)
if (scope == Scope.PER_CLASS)
else if (scope == Scope.PER_INSTANCE) advisor.removePerInstanceAspect(this);
But however the ClassInstanceAdvisor (a type of Advisor) keeps track of individual "aspect" instances mapped to AspectDefinition. That does'nt quite get cleared out in the above method call although the map that keeps AspectDefinition(s) itself does get cleared out in "advisor.removePerInstanceAspect(this);".
And then I proceed on to
1. Obtain the existing referenced AdviceBinding(s) from the AspectManager
2. Get its current InterceptorFactories
3. Regenerate the one particular interceptorfactory for which the AspectDefinition has changed
4. Create a new instance of the AdviceBinding with the same name and populate the new InterceptorFactories
5. And then call AspectManager.instance().addAdviceBinding(adviceBinding)
During the chain of invocations, PerInstanceAdvice does a call on ClassInstanceAdvisor.getPerInstanceAspect(aspectDefinition) and that basically returns the old instance of the AspectDefinition and not the newly updated one.
So if any attributes that may have changed in the AspectDefinition does not get picked up.
I have not tried the PER_VM and PER_CLASS aspect because I have some other issues (like NoClassDefFoundErrors) related to my packaging, as my aspects get deployed during run-time and so forth.
Does anyone have any opinions/comments/solutions to this subject? Any thoughts/ideas would be much appreciated. Essentially I'm trying to modify aspect definition custom attribute values on the fly and re-generating the advice bindings but unfortunately the new values don't quite reflected in the advice implementation. And I suspect the reason being the advice instances are somehow cached somewhere and not quite re-generated using the AspectDefinition.createAspect() when I regenerate the advice bindings
Finally figured out a way to get around the problem.
I sort of hacked the way I maintained AspectDefinitions to get around the problem of the WeakHashMap implementation in ClassInstanceAdvisor.aspectDefinitions. For some reason the old aspect definition was not getting flushed out of the WeakHashMap even though, AFAIK all references of the old instance was removed and a new one was created with a different "element" attribute. Basically I wanted the ability to modify custom attributes during run-time.
I named my AspectDefinition with the "name:hashCode" thus creating unique instances all the time. So when I do a "re-deploy" of the advice bindings, the ClassInstanceAdvisor is forced to get the new aspect definition and call AspectDefinition.createAspect().