[jira] Commented: (XMLBEANS-228) Element order is mixed up on document creation after calling substitute()

["Radu Preotiuc-Pietro (JIRA)" <xm...@xml.apache.org>]

    [ https://issues.apache.org/jira/browse/XMLBEANS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491035 ] 

Radu Preotiuc-Pietro commented on XMLBEANS-228:
-----------------------------------------------

I have reviewed the patches and even though I don't think I was the comitter that Lawrence was referring to in "this patch is not consistent with a chat I had with one of the committers", I do agree with the opinion that having substitution group members show up alongside the head element in content models is the 0.1% case and it's not worth the memory penalty of keeping track when substitution groups were used.

So I would propose we don't worry about this 0.1% case and we fix the more common case where you have substitution groups, but members of the substitution group can't appear in the same content model with the head. I have a fix for that and will check it in soon.




> Element order is mixed up on document creation after calling substitute()
> -------------------------------------------------------------------------
>
>                 Key: XMLBEANS-228
>                 URL: https://issues.apache.org/jira/browse/XMLBEANS-228
>             Project: XMLBeans
>          Issue Type: Bug
>          Components: XmlObject
>    Affects Versions: Version 2, Version 2.1
>         Environment: N/A
>            Reporter: Andreas Loew
>             Fix For: Version 2, Version 2.1
>
>         Attachments: substGroupTests.xsd, substitutionGroupFix.patch, substitutionGroupInSequence.xsd, SubstitutionGroupTest.java, xmlbeans228.patch, xmlbeans228_QNameSet.patch
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org