[
https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046339#comment-18046339
]
Susan Hert commented on XMLBEANS-661:
-------------------------------------
Yes, that's understandable, and I am wanting some way to provide a test just
having troubles understanding how to exercise this code path.
One difficulty I have at the moment is when I try to run the tests using
{{./gradlew test -PjdkVersion=17}}
I get a compilation errors like this (on MacOS) because the casing for the
generated class name and the file name do not match:
{{xmlbeans/build/generated/sources/sSIMPLE/test/java/noNamespace/RESULTDocument.java:22:
error: interface ResultDocument is public, should be declared in a file named
ResultDocument.java}}{{{} public interface ResultDocument extends
org.apache.xmlbeans.XmlObject{}}}{{{{}}{ {}}}
This is true for a clean enlistment or with my changes. It's so odd because I
successfully ran tests with the same command before and can't think what may
have changed. Does this ring any bells?
> 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,
> 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]
