[
https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18044454#comment-18044454
]
Susan Hert edited comment on XMLBEANS-661 at 12/11/25 5:40 PM:
---------------------------------------------------------------
I have looked into making this resolution ordering configurable, but without
making much headway. The XmlOptions object seems to largely come into play when
parsing documents, but this issue happens when loading an object, and at the
point where this happens there is no XmlOptions object in sight (at least not
that I can find).
I have confirmed that the test provided with the fix for XMLBEANS-648 still
passes with my update.
Admittedly, I don't really understand the pathways through this code, but is
there a use case you know of where some type system would be findable with both
the resourceLoader and the classLoader, but the one from the resourceLoader is
different from the one provided by the classLoader and is to be preferred?
was (Author: JIRAUSER311767):
I have looked into making this resolution ordering configurable, but without
making much headway. The XmlOptions object seems to largely come into play when
parsing documents, but this issue happens when loading an object, and at the
point where this happens there is no XmlOptions object in sight (at least not
that I can find).
I have confirmed that the test provided with the fix for XMLBEANS-648 still
passes when my update.
Admittedly, I don't really understand the pathways through this code, but is
there a use case you know of where some type system would be findable with both
the resourceLoader and the classLoader, but the one from the resourceLoader is
different from the one provided by the classLoader and is to be preferred?
> 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
>
>
> [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]
