[jira] [Commented] (XMLBEANS-661) Unable to resolve beans with classloader because DefaultClassLoaderResourceLoader is used first

    [ https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18086587#comment-18086587 ] 

PJ Fanning commented on XMLBEANS-661:
-------------------------------------

I haven't looked at XmlBeans in a months, apologies.

The XMLBeans661Test.tgz reproduces the issue and [https://github.com/apache/xmlbeans/commit/bf0b1412fb94d1c8a80f6f16d128076e9efd324f] fixes it.

I haven't been able to get a unit test in the XMLBeans suite to reproduce the issue.

[https://github.com/apache/xmlbeans/pull/37] passes with and without the classloader change.

I'll leave the change merged but I might try a bit more testing before any 5.4.0 release. That is not yet scheduled and it could be a while.

> 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
>             Fix For: 5.4.0
>
>         Attachments: SchemaTypeLoader__typeSystemForName.patch, XMLBeans661Test.tgz, 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)