[
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