[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Generated AjcClosure classes
|
Hi,
thanks for the code. Half an hour after sending you the mail, and reading more code, I came up with the same solution, basically, which means I was right :).
Cheers,
Silviu
On Dec 3, 2009, at 3:44 PM, Simone Gianni wrote:
> Hi Silviu,
> in Magma I'm using the following :
>
> public class AspectJClassTransformer extends ClassLoader implements
> ClassTransformer, WeavingClassLoader {
> // Various method of a classloader
> // ....
>
> // Implements GeneratedClassHandler.acceptClass
> public void acceptClass(String name, byte[] bytes) {
> System.out.println("AspectJ pushed " + name);
> }
>
> // ....
>
> }
>
> On system out, i see :
>
> AspectJ weaving org.apache.magma.settings.SettingsHolder
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure1
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure3
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure5
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure7
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure9
>
> So, in a class loader system, the accept method receives closures. I
> don't do anything special with them (except defining them in my current
> classloader). As i said before, I don't know if in an agent the same
> rules apply.
>
> Simone
>
>
>
> Andrica Silviu wrote:
>> 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
>>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> --
> 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
