[
https://issues.apache.org/jira/browse/XMLBEANS-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714543#comment-17714543
]
PJ Fanning commented on XMLBEANS-636:
-------------------------------------
I added
[https://github.com/apache/xmlbeans/commit/a29e94919c92bfa75e62b34fca407b3bfab42c29]
This actually passes on my laptop.
The ant scripts are all broken so I'm not relying on them. We use gradle to
build now.
If you want to debug the passing tests, you can run `./gradlew test` and the
classes for the schema will be generated. In your IDE, you should then be able
to run the test (which wouldn't work if the generated classes for schema were
not yet created).
Of course, the CI build might fail. I will check later to see how that gets on.
> 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]
