Hi PJ, Thanks for the comments. The AbstractType sample included in the XMLBeans source repository reproduces the issue as-is. It does not compile without some tweaks, so I forked the repository with a fix. You can find it here: https://github.com/JeSuisAbraham/xmlbeans/tree/AbstractTypes/samples/AbstractTypes As mentioned in the README, you need to set the XMLBEANS_HOME environment variable prior to calling ant run.
Should I create a ticket in issues.apache.org JIRA for further discussions? Thanks, François Le 2023-04-11 05:38, « PJ Fanning » <fannin...@yahoo.com.inva <mailto:fannin...@yahoo.com.inva>LID> a écrit : Apologies for the spam response. This bot has been reported - see https://issues.apache.org/jira/browse/INFRA-24452 <https://issues.apache.org/jira/browse/INFRA-24452>. If anyone else on this list has moderator rights, could they have a look? Francois - I'm not sure what to do with your issue. We have many XMLBeans v5 users and no reports like this. We have issues.apache.org JIRA and this is a better place to discuss issues. That said, you have not produced a reproducible use case and I doubt whether any XMLBeans contributor will spend time on this - but maybe they will. Like all OSS software, the primary onus is on you to get it to work and if you find an issue you need to make it as easy as possible for other users to help. Did you regenerate the generated source code with XMLBeans 5? You won't be able to use the source generated with XMLBeans 3 with the XMLBeans 5 runtime. We use semver versioning and v5 is 2 major versions ahead of v3. On Tuesday 11 April 2023 at 10:41:47 GMT+2, Francois Rajotte (frrajott) <frraj...@cisco.com.inva <mailto:frraj...@cisco.com.inva>lid> wrote: 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 <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 <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 <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 <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 <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 <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 --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@poi.apache.org <mailto:user-unsubscr...@poi.apache.org> For additional commands, e-mail: user-h...@poi.apache.org <mailto:user-h...@poi.apache.org>
