Sorry Andy, I forgot to mention the recursive invocation problem when using the weaver as a system classloader. I tried to work around it by putting everything on 'aj.class.path' which made the exception go away but did not do anything with regard to aspect weaving.
-- Alexander Kriegisch https://scrum-master.de Andy Clement: > Re: > -Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader > > Been a while since I've tried that, I half expected that property not > to work, but (on Java8) if I set it and I set aj.aspect.path then I > see WeavingURLClassLoader kick in and try to work - it gets stuck in a > recursive invocation problem though. Not sure what that is. > > Caused by: java.lang.IllegalStateException: recursive invocation > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429) > at java.util.ServiceLoader.loadInstalled(ServiceLoader.java:568) > at java.util.ResourceBundle.<clinit>(ResourceBundle.java:376) > at org.aspectj.weaver.WeaverMessages.<clinit>(WeaverMessages.java:19) > at org.aspectj.weaver.bcel.ClassPathManager.addPath(ClassPathManager.java:103) > > > Re: weaving java/javax > > I think we've often said if you need to do that, do it offline and > used a patched rt.jar/equivalent as it is more reliable. I can fully > believe the JDK has moved on in terms of class loading mechanisms and > AspectJ hasn't kept up. > > > Alexander Kriegisch: > >> 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: >> >> > 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 >> aspectj-users@eclipse.org >> <mailto:aspectj-users@eclipse.org> >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users