4 Replies Latest reply on Aug 18, 2004 6:23 PM by rkadayam

    Regeneration of Aspect instances if AspectDefinition is upda

    rkadayam Newbie

      Although the ClassInstanceAdvisor.apsects is a WeakHashMap, the previously created aspect instances don't get removed until a "redeploy" of the whole application is done. I have a requirement of doing "on the fly" updates to aspect definitions and so would need the Aspect instances regenerated so that it does a fresh XmlLoadable.import to get the updates.

      All of these internal datastructures are private and protected so I can't induce an explicit regeneration of the aspect instances or can I?

      Would it be okay if AspectDefinition.clearAdvisors() to do an explicit cast of ClassInstanceAdvisors and clear this particular aspect instance , in fact is this a bug ?

      Any, thoughts ?


        • 1. Re: Regeneration of Aspect instances if AspectDefinition is
          Bill Burke Master

          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.


          • 2. Re: Regeneration of Aspect instances if AspectDefinition is
            rkadayam Newbie

            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.


            • 3. Re: Regeneration of Aspect instances if AspectDefinition is
              rkadayam Newbie

              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


              • 4. Re: Regeneration of Aspect instances if AspectDefinition is
                rkadayam Newbie

                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().