[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] Created: (XMLBEANS-228) Element order is mixed up on document creation after calling substitu
From:       "Andreas Loew (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2005-11-23 12:49:39
Message-ID: 1234300951.1132750179621.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

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


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: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]