[
https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045880#comment-18045880
]
Susan Hert commented on XMLBEANS-661:
-------------------------------------
We are using SpringBoot Embedded Tomcat and, to the best of my knowledge, a
parent-last classloader. We've had to hack the classloader a bit of other
reasons and are not opposed to having to do something else to make this work,
but the problem doesn't seem to be with a classloader not finding things in the
right order but with the fact that the non-null resource loader prevents the
use of the classloader at all. With this thought in mind I came up with a
different change that seems to also fix our problem and may be less disruptive
than my previous proposal. Namely, when the {{new SchemaTypeSystemImp}} is
created by {{SchemaTypeLoaderImpl::getTypeSystemOnClasspath}}, pass in the
existing {{_classLoader}} so it can possibly get used alongside the resource
loader.
The new patch is attached. Let me know what you think.
[^XMLBeans_661.patch]
> Unable to resolve beans with classloader because
> DefaultClassLoaderResourceLoader is used first
> -----------------------------------------------------------------------------------------------
>
> Key: XMLBEANS-661
> URL: https://issues.apache.org/jira/browse/XMLBEANS-661
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 5.2.1
> Reporter: Susan Hert
> Priority: Major
> Attachments: SchemaTypeLoader__typeSystemForName.patch,
> XMLBeans_661.patch
>
>
> [This
> commit|https://github.com/apache/xmlbeans/commit/82bcd3775c4643799d11581649815596aedd3520]
> for the fix of Issue #648 has introduced another problem that we are seeing
> when loading certain documents.
> In particular, the constructor of
> {{src/main/java/org/apache/xmlbeans/impl/schema/SchemaTypeSystemImpl.java}}
> changed from passing a {{null}} value as a {{resourceLoader}} to the
> {{build}} method for {{SchemaTypeLoaderImpl}} to passing in a {{new
> DefaultClassLoaderResourceLoader()}}. This has the consequence that
> {{SchemaTypeLoaderImpl::typeSystemForName}} now tries to get the type system
> on the classpath using the {{_resourceLoader}}, but, in our case, for some
> documents, the {{_classpathTypeSystems}} map is empty, and thus it returns a
> generic {{SchemaTypeSystemImpl}} that has no classloader and won't return any
> of our XML beans, which then later causes a {{ClassCastException}} because
> the object returned is a base class object.
> Previously, when the {{_resourceLoader}} was {{null}}, {{typeSystemForName}}
> used the non-null {{_classLoader}} and found a type system with a classpath
> that could resolve to our beans.
> This does not happen for all of our beans, and I've not been able to track
> down what differentiates the problematic ones from the happy ones, butÂ
> running out tests with an updated version of xmlBeans that includes this
> patch seems to have resolved our issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
