François Rajotte created XMLBEANS-636:
-----------------------------------------
Summary: Incorrect processing of abstract XML types defined in
multiple schema files
Key: XMLBEANS-636
URL: https://issues.apache.org/jira/browse/XMLBEANS-636
Project: XMLBeans
Issue Type: Bug
Affects Versions: Version 4.0.0, Version 5.1.1
Reporter: François Rajotte
Attachments: AbstractType_xmlbeans-3.0.0.log,
AbstractType_xmlbeans-5.1.1.log
We have observed a regression when upgrading XMLBeans from version 3.0.0 to
5.1.1.
The issue is related to how concrete and abstract types are handled in XMLBeans
when they are defined in different schema files.
I have enhanced the existing "AbstractTypes" sample provided in the XMLBeans
repository to show the regression. You can find the code in my private branch
here:
[https://github.com/JeSuisAbraham/xmlbeans/tree/AbstractTypes/samples/AbstractTypes]
The "AbstractTypes" sample consists of two schema files.
The abstractBase.xsd schema defines the document root, which contains abstract
"figures".
The myfigures.xsd schema contains concrete implementations of these abstract
figures: a "square" and a "circle".
Three tests are performed:
* buildDocument: builds a document "top-down". Creates a document, adds
abstract objects and specializes them into concrete objects.
* buildDocument2: builds a document "down-top". Creates a document, creates
the concrete objects and adds them to the document.
* parseDocument: parses a document containing concrete types.
All of these tests are broken in XMLBeans 4.+ whereas they worked in XMLBeans
3.x.
I have attached the output of this test program when ran against XMLBeans 3.0.0
and XMLBeans 5.1.1 for comparison.
The differences between v3.0.0 and v5.1.1 are:
* buildDocument: In v5.1.1, the test throws a ClassCastException when trying
to coerce an abstract object down to a concrete implementation.
* buildDocument2: In v5.1.1, the document output does not contain the xsi:type
attributes. The resulting document is not schema-valid.
* parseDocument: In v5.1.1, the concrete objects are not recognized as such.
They remain of the abstract type. The parsed document object in not
schema-valid.
Using a debugger, we've found the following differences between v3.0.0 and
v5.1.1:
The concrete types are resolved here using a SchemaTypeLoader:
[https://github.com/apache/xmlbeans/blob/fb3f015826f1378b10178b7d4fe71bfe133c30ca/src/main/java/org/apache/xmlbeans/impl/schema/SchemaTypeImpl.java#L937]
In 3.x.x, the schema type loader is of type "SchemaTypeLoaderImpl", and will
fetch both locally in its own schema and in other schema type systems loaded
into the system:
[https://github.com/apache/xmlbeans/blob/a7cdcb1a37319d69eeef31a90badf9d2bb02de81/src/main/java/org/apache/xmlbeans/impl/schema/SchemaTypeLoaderImpl.java#L372]
In 5.x.x, the schema type loader is of type "TypeSchemaHolder", defined in the
bean jar itself, and extends "SchemaTypeSystemImpl". This schema type loader
only looks for types into its own schema:
[https://github.com/apache/xmlbeans/blob/a7cdcb1a37319d69eeef31a90badf9d2bb02de81/src/main/java/org/apache/xmlbeans/impl/schema/SchemaTypeSystemImpl.java#L1009]
This change in behavior seems related to XMLBEANS-536.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
