[
https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048456#comment-18048456
]
Susan Hert commented on XMLBEANS-661:
-------------------------------------
I have finally been able to create a repro case for this problem. I couldn't
find a way to do this within the xmlbeans code base, but I've attached a file
with the repro.
In summary, the repro requires:
* Two XSDs, one that imports a type from the other
* The two XSDs must be associated with different TypeSystems (which, I think,
means different jar files with the second jar built referencing the first jar
on the classpath)
Without two different type systems, the problem does not recur because there
are no differences in the classloader.
You can read the notes at the start of the XMLBeansTest.java file for what I've
done to set up the repro case. This file includes compiled jars and the
compiled class file, but also instructions on building them if necessary. The
version of XML beans used to compile the classes does not seem to make a
difference; you just need to change the version of xmlbeans on the classpath
when running the test to see the problem. I've run with version 5.2.0 (no
problem), 5.3.0 (problem), and my patched version (no problem).
Let me know if it doesn't make sense or if you need more info.
[^XMLBeans661Test.tgz]
> 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,
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
