Susan Hert created XMLBEANS-661:
-----------------------------------
Summary: 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
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, when 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]
