Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Generated AjcClosure classes

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
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users



Back to the top