We need some Information. 1. Where are you from? 2. Which service do you want ? [ Writing+Publishing+Link insertion ] 3. Please Share Your Website URL. 4. Your Website General or [ Casino / CBD / Gambling / Betting ] Related? 5. Are you a *Reseller* or from an *Agency*? [Note: Minimum *200* Usd Order Per Month]
*Best Regards* Support Team Email: [email protected] Skype: live:.cid.e794949374bfa80a WhatsApp: 8801826574180 *Telegram: Gpostingltd <https://t.me/gpostingltd>* On Tue, Apr 11, 2023 at 2:41 PM Francois Rajotte (frrajott) <[email protected]> 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 > 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 >
