Re: [aspectj-users] LTW and JRE classes

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

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?