[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
