One more question: What exactly is it good for to be able to replace the system classloader by WeavingURLClassLoader via:
-Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader For me this does not do anything without an additional weaving agent attached via '-javaagent:...'. Can you explain, maybe? Source code reference: https://github.com/eclipse/org.aspectj/blob/8c6b3ae13b105ce9bb9559de0ee4752cab5ba81c/loadtime/src/org/aspectj/weaver/loadtime/WeavingURLClassLoader.java#L48 -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch: > I tried '-verbose:class' both with normal LTW configuration and with > the weaving agent additionally prepended to the boot classpath via > '-Xbootclasspath/p:/my/path/aspectjweaver.jar"'. Except for the weaver > classes being loaded earlier in the latter case, the result is the > same: > > Only classes from AppClassLoader yield any AspectJ log message, woven > or not. JRE classes are being ignored, I see no other classloader > being attached. Actually there does not seem to be any specific debug > logging for names of attached classloaders at all, I only indirectly > see things like "[AppClassLoader@18b4aac2] debug not weaving > 'a.b..C'". > > > Andy Clement: > >>> Furthermore, both '-verbose:class' and '-verbose=class' yield >>> warnings >> >> That's not a weaver option, it is a JVM option for showing class >> loading. I thought pairing that with the -debug weaver option might >> show java types being loaded by the JVM and if there was no immediate >> weaver message then they weren't getting to the weaver. >> >> It is interesting what classloaders weavers get attached to. I can't >> what the current class loader hierarchy is in Java8 - do you only see >> the one weaver attached to application related class loader? >> >> >> Alexander Kriegisch: >> >>> Actually, I am still running Java 8, so modules are not an issue >>> here. >>> >>> Furthermore, both '-verbose:class' and '-verbose=class' yield >>> warnings: >>> >>> [MethodUtil@1e51f2fa] warning Cannot configure weaver with option >>> '-verbose:class': unknown option >>> >>> I run with these settings: >>> >>> <weaver options="-showWeaveInfo -verbose -debug >>> -Xset:weaveJavaxPackages=true,weaveJavaPackages=true"> >>> <include within="javax..*"/> >>> <include within="java..*"/> >>> <include within="org.aspectj..*"/> >>> </weaver> >>> >>> I see nothing on the console indicating that any JRE classes are >>> even visible to the classloader. I even created a main class >>> starting my other main class via Class.forName(), Class.getMethod() >>> and Method.invoke() in order to avoid javax or java JRE imports in >>> my main class, trying to avoid that the weaver kicks in too late. It >>> seems as if the weaver does not get attached to the right >>> classloader. Should I do more than just '-javaagent:...' and also >>> add the weaver to the boot classpath or something? >>> >>> I found a test related to javax classes, but that one is kinda >>> cheating because it tests with own classes in javax package not with >>> real JRE classes: >>> >>> https://github.com/eclipse/org.aspectj/tree/master/tests/features160/weavingJavaxPackage >>> >>> I really need some help to get started here. >>> >>> >>> Andy Clement: >>> >>>> I feel like they used to work but there were gotchas. For example >>>> the JVM loads up some types before the LTW infrastructure can even >>>> get involved and those can't be woven. I don't actually recall if >>>> we have testcases for this but I wouldn't be surprised if they >>>> weren't there. I guess you have tried them and they don't work - I >>>> wonder if you were test weaving something that would be loaded >>>> early? It would be interesting to attempt it with a -verbose:class >>>> and verify not attempting to weave things loaded before the 'LTW is >>>> active' type messages come out. Will it work with modules in recent >>>> Javas? That seems unlikely. >>>> >>>> But it could be the kind of classloaders in use in regular Java now >>>> don't allow weaver attachment, I honestly haven't kept up to speed >>>> on that - and maybe that prevents them working at all. A run of LTW >>>> with the debug option on for the weaver should show the types the >>>> weaver is being exposed to. If those are java/javax then they >>>> should be weavable. >>>> >>>> >>>> Alexander Kriegisch: >>>> >>>>> The AspectJ documentation still mentions things like >>>>> >>>>> -Xset:weaveJavaxPackages=true >>>>> -Xset:weaveJavaPackages=true >>>>> >>>>> or for LTW >>>>> >>>>> <include within="javax.*"/> >>>>> <include within="java.*"/> >>>>> <include within="org.aspectj.*"/> >>>>> >>>>> (I think "java..*" would be correct syntax, BTW.) >>>>> >>>>> None of these work. Yes, there are valid cases in which users >>>>> might want to use LTW on JRE classes. The only way I could ever >>>>> weave into the JRE (execution joinpoints, not just call from my >>>>> own woven code) was binary weaving and creating my own (subset of) >>>>> JRE, prepending it to the boot classpath. But that's not nice and >>>>> I never tried with modularised Java 9+, which might work or not. >>>>> >>>>> Before I create a Bugzilla ticket I would like to get a maintainer >>>>> opinion. Is there any chance to make this work with AspectJ LTW? >>>>> Is is maybe possible already and I just do it wrong? _______________________________________________ aspectj-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
