[
https://issues.apache.org/jira/browse/XMLBEANS-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714601#comment-17714601
]
François Rajotte commented on XMLBEANS-636:
-------------------------------------------
Thanks for integrating the test into gradle. Your commit also passes on my side.
I believe the issue occurs when the abstract type and concrete types are
defined in different schemas, with the schema containing the concrete type
referencing the schema containing the abstract type. In your commit, the two
types are compiled together in the same schema, so the issue is not reproduced.
I built upon your commit and moved the concrete types into their own schema. I
messed around with the gradle build file to make this work and while it's not
the prettiest, it should be sufficient to reproduce the issue.
You can find that commit here:
[https://github.com/JeSuisAbraham/xmlbeans/commit/bac2deb7ca3c8a57f89964925fcffc00efe0f85b]
or the whole branch here:
[https://github.com/JeSuisAbraham/xmlbeans/tree/XMLBEANS-636]
For reference, I get the following errors:
{noformat}
java.lang.ClassCastException: class abstractFigures.impl.ShapeImpl cannot be
cast to class figures.Circle (abstractFigures.impl.ShapeImpl and figures.Circle
are in unnamed module of loader 'app') at
scomp.abstractTypes.detailed.AbstractTypesTest.buildDocument(AbstractTypesTest.java:82){noformat}
{noformat}
org.opentest4j.AssertionFailedError: expected: <true> but was: <false> at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//scomp.abstractTypes.detailed.AbstractTypesTest.testBuildDocument2(AbstractTypesTest.java:37){noformat}
{noformat}
org.opentest4j.AssertionFailedError: Shape #1 is a Circle? ==> expected: <true>
but was: <false> at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:211) at
app//scomp.abstractTypes.detailed.AbstractTypesTest.testParseDocument(AbstractTypesTest.java:54)
{noformat}
> 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]
