NullPointerException in createClassInstance in org.opensaml.xml.XMLConfigurator
Basics
Logistics
Basics
Logistics
Description
In a stand-alone Java application using the system classloader, when using OpenSAML to verify a SAML assertion, the function createClassInstance is called (for example, to create an instance of XSAnyBuilder) and causes a NullPointerException.
This happens because the getClassLoader() function may return null if the class was loaded by the system, or bootstrap, class loader. I tested with Sun JRE versions 1.5, 1.6, and 1.7 and they all do return null for the bootstrap classloader.
Here are the relevant lines from XMLConfigurator in xmltooling version 1.3.4:
328 ClassLoader classLoader = this.getClass().getClassLoader(); 329 Class clazz = classLoader.loadClass(className);
When running in a web container or Junit test in an IDE, there is a custom classloader hierarchy in place and everything works fine. But in an independent environment using the system class loader, the code throws a NullPointerException.
This can be easily fixed by inserting the following line between the two lines shown:
I made this patch in my own project and it's working fine now.
Hope you will adopt this little fix in the next release.
Environment
Stand-alone Java application using system classloader
Activity
Brent Putman
March 23, 2013 at 12:27 AM
Fixed in r803.
Brent Putman
September 21, 2012 at 7:55 PM
(edited)
I was trying to reproduce this and couldn't. I just want to clarify what you are doing here - are you just invoking your program with 'java -cp <classpath>', with the OpenSAML jar files and dependencies listed on the classpath there, or something else? What platform and OS was this on? It's possibly there are implementation differences between Windows, Linux and MacOS JVM's.
The change you suggest is small and probably wouldn't have any adverse effect, I just want to fully understand what's going on.
This also jogged my memory that in OpenSAML v3 I had tentatively changed this code to use the thread context classloader, which at the time seemed more correct given some of the other loading issues that the v3 config and init redesign was attempting to address. So perhaps that is also something to consider (although want to make sure doesn't introduce any problems). See:
In a stand-alone Java application using the system classloader, when using OpenSAML to verify a SAML assertion, the function createClassInstance is called (for example, to create an instance of XSAnyBuilder) and causes a NullPointerException.
This happens because the getClassLoader() function may return null if the class was loaded by the system, or bootstrap, class loader. I tested with Sun JRE versions 1.5, 1.6, and 1.7 and they all do return null for the bootstrap classloader.
Here are the relevant lines from XMLConfigurator in xmltooling version 1.3.4:
328 ClassLoader classLoader = this.getClass().getClassLoader();
329 Class clazz = classLoader.loadClass(className);
When running in a web container or Junit test in an IDE, there is a custom classloader hierarchy in place and everything works fine. But in an independent environment using the system class loader, the code throws a NullPointerException.
This can be easily fixed by inserting the following line between the two lines shown:
if( classLoader == null ) { classLoader = ClassLoader.getSystemClassLoader(); }
I made this patch in my own project and it's working fine now.
Hope you will adopt this little fix in the next release.