[ http://issues.apache.org/jira/browse/XMLBEANS-228?page=all ]
Andreas Loew updated XMLBEANS-228:
----------------------------------
Attachment: substitutionGroupInSequence.xsd
Sample XSD file as needed for the JUnit test case
> Element order is mixed up on document creation after calling substitute()
> -------------------------------------------------------------------------
>
> Key: XMLBEANS-228
> URL: http://issues.apache.org/jira/browse/XMLBEANS-228
> Project: XMLBeans
> Type: Bug
> Components: XmlObject
> Versions: Version 2.1, Version 2
> Environment: N/A
> Reporter: Andreas Loew
> Fix For: Version 2.1, Version 2
> Attachments: SubstitutionGroupTest.java, substitutionGroupFix.patch,
> substitutionGroupInSequence.xsd
>
> When trying to create XML documents with XMLBeans 2.x using xmlText() or
> save() that use substitution groups, usage of the substitute() method will
> mix up the order of the XML document (the order will remain correct when
> substitute() will not be called).
> We have attached a test case (schema XSD, JUnit test) that demonstrates the
> failure and also attached a patch against plain XMLBeans 2.0.0 that shows
> where the problem is and what is needed to fix problem (although currently at
> the cost of a quite severe perfomance penalty, as I am not an expert in
> XMLBeans internals):
> For the test case, XMLBeans 2.0.0 as well as the current SVN snapshot both
> fail as they return
> <?xml version="1.0" encoding="UTF-8"?>
> <Person
> xmlns="urn:www-apache-org:SubstitutionGroup/substitutionGroupInSequence">
> <FirstCommentElement>ThirdElement</FirstCommentElement>
> <FirstName>FirstElement</FirstName>
> <LastName>SecondElement</LastName>
> </Person>
> instead of
> <?xml version="1.0" encoding="UTF-8"?>
> <Person
> xmlns="urn:www-apache-org:SubstitutionGroup/substitutionGroupInSequence">
> <FirstName>FirstElement</FirstName>
> <LastName>SecondElement</LastName>
> <FirstCommentElement>ThirdElement</FirstCommentElement>
> </Person>
> as would be correct (and will be returned after applying the patches
> provided).
> Basically, the main problem is that
> XmlObjectBase#getElementEndingDelimiters() after having called
> SchemaProperty#getJavaSetterDelimiter(), does not take into account that the
> QNameSet returned by getJavaSetterDelimiter() does not yet include the "alias
> names" - i.e. possible substitutions - of those elements that happen to be
> heads of substitution groups.
> The patch for XmlObjectBase adds the missing substitutions to this QNameSet.
> This will fix the base problem, but so far at the cost of performance: In
> order to simulate a (non-existing) QNameSet iterator on the set of
> JavaSetterDelimiters, we have not been able to find a more intelligent
> solution than to iterate over the complete array of SchemaGlobalElements and
> check each head of a substitution group for inclusion in the QNameSet (using
> QNameSet#contains()). This definitely is suboptimal and should be replaced by
> an optimized implementation done by somebody who is familiar with the
> internals of XMLBeans. (Sorry!)
> Unfortunately, while creating the first fix, we ran into a second (small)
> issue:
> The static method QNameSet#forArray() does mistakenly pass null instead of
> new HashSet() to the private constructor, which results in a
> NullPointerException. The second fix (also included in the patch) will fix
> this problem.
> Please get back to me in case you need any additional details.
> Thanks & best regards,
> Andreas Loew & Patrik Streicher
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
