[jira] [Updated] (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:all-tabpanel ]

PJ Fanning updated XMLBEANS-661:
--------------------------------
    Fix Version/s: 5.4.0

> 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)