ClassCastException: org.opensaml.xml.schema.impl.XSAnyBuilder cannot be cast to org.opensaml.core.xml.XMLObjectBuilder
Basics
Logistics
Basics
Logistics
Description
When attempting to use OpenSAML v3.1.1 (as leveraged by pac4j-saml) with a classloader that happens to put xmltooling-1.4.4.jar ahead of, for example, opensaml-core-3.1.1.jar, then the following error is received:
This appears to be caused by both jars containing /default-config.xml (among other similar entries). When org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer#init executes this:
AbstractXMLObjectProviderInitializer#init
The classloader will pick the first resource at that name/path from the list of jars. So, instead of picking the default-config.xml from opensaml-core, it can pick the file from xmltooling, which results in the previously mentioned ClassCastException.
My naive assumption is that to fix this, the `configs` field of org.opensaml.core.xml.config.XMLObjectProviderInitializer (and others) must be modified to specify resources with unique paths/names.
In my usage of OpenSAML, I will likely be reordering my classloader's classpath to put xmltooling-1.4.4.jar at the end of the path, but this feels fragile. Other jars that use org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer could introduce this same issue, and I wouldn't realize it until runtime.
This can easily be reproduced through the spark-pac4j-demo project, by manually altering the classpath to specify xmltooling-1.4.4.jar ahead of opensaml-core-3.1.1.jar. It's not limited to pac4j or spark, of course, as my intended usage is in a custom web framework where I first discovered the issue.
When attempting to use OpenSAML v3.1.1 (as leveraged by pac4j-saml) with a classloader that happens to put xmltooling-1.4.4.jar ahead of, for example, opensaml-core-3.1.1.jar, then the following error is received:
This appears to be caused by both jars containing /default-config.xml (among other similar entries). When org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer#init executes this:
AbstractXMLObjectProviderInitializer#init
The classloader will pick the first resource at that name/path from the list of jars. So, instead of picking the default-config.xml from opensaml-core, it can pick the file from xmltooling, which results in the previously mentioned ClassCastException.
My naive assumption is that to fix this, the `configs` field of org.opensaml.core.xml.config.XMLObjectProviderInitializer (and others) must be modified to specify resources with unique paths/names.
In my usage of OpenSAML, I will likely be reordering my classloader's classpath to put xmltooling-1.4.4.jar at the end of the path, but this feels fragile. Other jars that use org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer could introduce this same issue, and I wouldn't realize it until runtime.
This can easily be reproduced through the spark-pac4j-demo project, by manually altering the classpath to specify xmltooling-1.4.4.jar ahead of opensaml-core-3.1.1.jar. It's not limited to pac4j or spark, of course, as my intended usage is in a custom web framework where I first discovered the issue.
Looking forward to any assistance. Thank you!