[
https://issues.apache.org/jira/browse/XMLBEANS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492173
]
Radu Preotiuc-Pietro commented on XMLBEANS-310:
-----------------------------------------------
So let me understand where you think the problem is:
- is it that you don't get an exception saying that the type was not found? I
think that was deliberate because we are trying to not throw too many
exceptions because some users may consider this unfriendly: you can check
whether the operation succeeded by comparing the object returned with the
initial object, it says in the JavaDoc
- or is it that XmlBeans uses 'Thread.currentThread.getContextClassLoader()'?
This is a design decision; it has good parts and bad parts, I would say mostly
good parts.... also you can always use your own classloader to override this
behaviour so it should not be a problem.
Based on my current understanding of this issue I don't see what can be done
here, so I am going to resolve it unless I hear back...
> 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.
-
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]
