[jira] [Created] (XMLBEANS-636) Incorrect processing of abstract XML types defined in multiple schema files

["François Rajotte (Jira)" <ji...@apache.org>]

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-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org