Ciao Simone, could you give me a clue on how to catch the newly created closures? I was playing with Aj and its source code, but it seems that no matter what I try I cannot get it to work. The "accept" method I use only catches the original classes, never their closures.
Thanks a lot, Silviu On Dec 2, 2009, at 9:54 PM, Simone Gianni wrote: > Andy Clement wrote: >> You know, I'm on the verge of creating such a thing in AspectJ >> itself... I would be interested to here about your approach and how >> you know when to invalidate the cache, and what are you using as the >> cache key (some combination of the class itself hashed or something, >> plus the combination of aspects defined at the time, hashed or >> something?) >> > Hi Andy and Silviu, > I'm very happy you're planning such an improvement! > > I also tried to cache LTW classes, but did not find a way to invalidate > the right classes : when an aspect was somehow added, removed or > modified, I invalidated the entire cache and started from scratch, even > if probably only a few classes need reweaving. If a single comma was > added in a string in a single ITD, despite being a single byte > modification in a single class file, I had no option that reweaving > everything. > > I tried to use AspectJ matching system to know which aspects applied to > a given class, so that I could invalidate only classes affected by a > changed aspect. I can't remember how much I managed to do this, but even > if I managed to, I could not know if a changed aspect only modified it's > advice implementation or also it's "matching part", that is point cuts. > > If however it was possible to know whether an aspect changed its point > cuts or only its advice implementation (which happens most of the time, > especially when ITDs are used), it could be possible to invalidate only > classes that were matched by that aspect, and invalidate the full cache > only when the point cuts are changed. > > Applying the existing matching system is not a valid solution, cause > matching is the slowest part of the weaving process, and having to use > it to decide whether to invalidate a class or not makes the cache slower > than a full reweave. > > So, I think, the cache should save, as a state, not only the hashes of > defined aspects, but hashes of the point cuts of defined aspects. If > those are not changed (implicitly, no aspect has been added or removed), > then the model is still valid, and only classes affected by the modified > aspects needs to be reweaved to apply modified advice implementation. >> If AspectJ did this itself then the only user configuration would be a >> place to keep these woven classes so that they can be retrieved later. >> Do you have any specific requirements for the cache in your scenario? >> (or does anyone else reading this have requirements on a cache like >> this?) >> > This would be great and enough for my needs. Later probably a listener > on the cache could be useful, to integrate it in the case of a chain of > transforming classloaders like when there is AspectJ + JPA or similar > situations. > > Simone > > -- > Simone Gianni CEO Semeru s.r.l. Apache Committer > http://www.simonegianni.it/ > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
