[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Generated AjcClosure classes
|
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/