[
https://issues.apache.org/jira/browse/XMLBEANS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Preotiuc-Pietro resolved XMLBEANS-310.
-------------------------------------------
Resolution: Won't Fix
Fix Version/s: unspecified
> 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
> Fix For: unspecified
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]