[
https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18043163#comment-18043163
]
Susan Hert edited comment on XMLBEANS-661 at 12/11/25 5:55 PM:
---------------------------------------------------------------
I don't know that I'm going to be able to come up with a test for this since I
don't understand the path that leads to this kind of initialization.
As for making this configurable, I'll give it a shot, but one question is
whether the configuration should default to the ordering in my patch (which was
the behavior before the fix for XMLBEANS-648) or the ordering currently in the
code. Any thoughts on that?
was (Author: JIRAUSER311767):
I don't know that I'm going to be able to come up with a test for this since I
don't understand the path that leads to this kind of initialization.
As for making this configurable, I'll give it a shot, but one question is
whether the configuration should default to the ordering in my patch (which was
the behavior before the fix for XLMBEANS-648) or the ordering currently in the
code. Any thoughts on that?
> 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]
