[
https://issues.apache.org/jira/browse/XMLBEANS-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714691#comment-17714691
]
François Rajotte commented on XMLBEANS-636:
-------------------------------------------
Thanks again for the help PJ. I am very grateful of the time you spent on this.
Indeed, the two solutions you mention would work around the issue.
If nothing else, at least other people who run into the same problem when
upgrading from xmlbeans 3.x in the future will be able to find this ticket.
> 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
> Priority: Major
> Attachments: AbstractType_xmlbeans-3.0.0.log,
> AbstractType_xmlbeans-5.1.1.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
