Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
Version 2.3
-
None
-
None
-
Windows XP SP2
Description
Have two top-level elements with the same name, ABC_CLAIM_LIST, with no namespace. When compiled, each gets a unique package name: com.sample.xml.getclaimdetail and com.sample.xml.getclaimdetail.
All Factory parse methods inside an XmlBeans object use XmlBeans.getContextTypeLoader().parse... to create a new bean from existing XML. Even though the Factory parse methods pass the correct SchemaType to XmlBeans.getContextTypeLoader().parse, the parser is still confused as to which SchemaType to use for parsing.
The ABCCLAIMLISTDocument object in both com.sample.xml.getclaimdetail and com.sample.xml.getclaimlist has a different signature:
com.sample.xml.getclaimlist.ABCCLAIMLISTDocument = schemaorg_apache_xmlbeans.system.sB4F9EC0CC2C260E788CC18CB0CCCE5B4
com.sample.xml.getclaimdetail.ABCCLAIMLISTDocument = schemaorg_apache_xmlbeans.system.s19D0767C491A818B054FB30458612045
It appears that there is a bug in the XmlBeans parser - it's guessing which SchemaType to use for parsing the xml string, even though it already has the proper information available. So to avoid confusion, you have to use XmlOptions to explicitly specify the SchemaType for parsing:
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setDocumentType(com.example.xml.getclaimlist.ABCCLAIMLISTDocument.type);
try
{ document=com.example.xml.getclaimlist.ABCCLAIMLISTDocument.Factory.parse(xml, xmlOptions); }catch(XmlException xmle){
}
If calling the Factory.parse method without passing xmlOptions, will get ClassCastException because parse will attempt to use the com.example.xml.getclaimdetail.ABCCLAIMLISTDocument SchemaType.
This is only necessary when you know there's duplicate element names involved. Not sure why the parser can't figure that out on its own, but this will work