Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Won't Fix
-
None
-
None
-
AXIS2 version 1.1
Tomcat version 5.5
Description
In situations where, at runtime, a compiled schema for an XML element (XML type name) is being looked for (this happens e.g. when the XmlObject.substitute() operation is invoked) a resource is loaded via Classloader.getResourceAsStream() (see SchemaTypeLoaderImpl.java)
The problem is, that the Classloader of the current thread ('Thread.currentThread.getContextClassLoader()
is used instead the Classloader of an already loaded class (e.g.: classname.class.getClassLoader()).
This implementation works as long as it is not used within an AXIS2 service. In this case all classes and resources are located in an .aar archive. At load time this file is in the classpath and the XML-schemas and compiled classes are found. But, later when a service operation is invoked, the classloader retrieved with 'Thread.currentThread().getContextClassLoader() is of type WebappClassLoader instead of org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl. And this WebappClassLoader does NOT look within the .aar file for the schema, therefore substitude does not have the correct types available at runtime.
Oh and, there is also no error message in this case stating that a class couldn't be found/loaded!
Our workaround to this problem ATM is, setting the thread's contextClassLoader to be the class loader of a class contained in our web application, first thing each time an operation of our webservice is invoked. But a fix to this problem would of course be highly appreciated!
ps.: I will also crosspost this bugreport in AXIS2 since this problem is closely related to AXIS2, which probobably should hand down a better suited class loader.