Hi, We have begun the process of upgrading from XMLBeans 3.x.x to 5.x.x, with jdk17. We make use of abstract types in schema files, whose concrete implementations are in different schema files. As part of building objects containing these types, XMLBeans tries to coerce the abstract type into its concrete type. This no longer works.
I have gone back to a (very old) sample of XMLBeans code that uses abstract type in different schema files: https://xmlbeans.apache.org/samples/AbstractTypes.html The build.xml file requires a bit of rework to make it work against xmlbeans 5.x.x, but it’s not too bad: * Replace xbean.jar references with new jar name. (or create a softlink) * Modify xmlbeans.classpath to include all jars under ${xmlbeans.lib} (*.jar) * Remove java 1.4 source restriction. This sample program fails to coerce an abstract type into its concrete type. It gives the following exception: Exception in thread "main" 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 org.apache.xmlbeans.samples.abstracttypes.AbstractTypes.buildDocument(AbstractTypes.java:56) at org.apache.xmlbeans.samples.abstracttypes.AbstractTypes.main(AbstractTypes.java:29) What we noticed is the following: At this line, XMLBeans tries to coerce an abstract type into its concrete type: https://github.com/apache/xmlbeans/blob/fb3f015826f1378b10178b7d4fe71bfe133c30ca/src/main/java/org/apache/xmlbeans/impl/store/Cur.java#L2486 Here, we try to resolve the concrete type, and XMLBeans fetches a "schema type loader" to do that: https://github.com/apache/xmlbeans/blob/fb3f015826f1378b10178b7d4fe71bfe133c30ca/src/main/java/org/apache/xmlbeans/impl/values/XmlObjectBase.java#L905 We query the schema type loader here: 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 At this point, the concrete type fails to load, and the type remains abstract. This causes all sorts of issues down the line; e.g. the resulting XMLObject is invalid (validate() returns false), the serialized version doesn’t contain the xsi-type, and possibly other kinds of issues. Is this a known regression of XMLBeans sometime between 3.x.x and 5.x.x? Is there some new configuration that is required during compilation of the schemas to make this use case work? Thanks for the help, François
