Community
Participate
Working Groups
We are using an updated version of Alex Vasseur's LTW agent for AspectJ (based on AspectWerkz) to do load-time weaving on a 1.4 VM. The agent is loaded from the bootstrap loader. However, a user has reported this NPE (see http://www.glassbox.com/forum/forum/viewthread?thread=67). AspectWerkz - INFO - Pre-processor org.aspectj.ext.ltw13.ClassPreProcessorAdapter loaded and initialized [AppClassLoader@7b7072] warning parse definitions failed -- (NullPointerException) null null java.lang.NullPointerException at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.parseDefinitions(ClassLoaderWeavingAdaptor.java:180) at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:127) ... In this case, the code is assuming that ClassLoader.getSystemClassLoader() is already set, but when the weaver is loaded through the bootstrap loader that appears to not be a good assumption. I propose to avoid this problem by testing for the system loader like this, so as to enable 3rd party agents that might run before the system loader is set: if (loader!=null && loader.equals(ClassLoader.getSystemClassLoader())) { I will be providing our user a patched version of AspectJ to test with this change to see if it does fix the problem.
Created attachment 50659 [details] Proposed fix: patch to loadtime module
Ron, Thanks for the patch. I'd actually like to get rid of the undocumented "feature" ("-Daj5.def=...") altogether that is only there for testing. It means we don't test LTW in a representative way which has meant on at least one occasion (Bug 120473 "Don't Create Separate Weaving Adaptors for Reflection Loaders") we have been unable to reproduce problems. Unfortunately both you (http://rbodkin.blogs.com/ron_bodkins_blog/2005/10/websphere_loadt.html) and Alex (http://blogs.codehaus.org/people/avasseur/archives/001140_aspectj_5_load_time_weaving_with_java_13_using_aspectwerkz.html) have referenced it in your blogs even though there is no mention of it in the AspectJ LTW documentation. I trust you do not rely upon it. I'd also like to add a test to the suite for these JDK 1.4 agents.
I now have a testcase that not only verifies this fix but will also give us an environment to test custom 1.3/1.4 LTW agents in the future. It involves prepending a replacement java.net.URLClassLoader to the bootclasspath which intercepts class defining and calls Aj, appending AspectJ to the bootclasspath, and finally specifying a custom SecurityManger using -Djava.security.manager. This will be loaded and woven _before_ the class loader hierarchy initialization is complete and when ClassLoader.getSystemClassLoader() will return null.
Fix available in aspectj-DEVELOPMENT-20061003103716.jar
iplog
