XmlObject.substitute() does not work when XMLBeans are used in conujunction
with AXIS2 and run in a servlet container. Other operations might be affected
by this as well.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: XMLBEANS-310
URL: https://issues.apache.org/jira/browse/XMLBEANS-310
Project: XMLBeans
Issue Type: Bug
Components: XmlObject
Environment: AXIS2 version 1.1
Tomcat version 5.5
Reporter: Severin Ecker
Priority: Minor
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
