Thanks Chad. The test was very helpful and seems to be passing now after the fix I just committed. We have to force a full expansion of the node being transferred while it still has a reference to its original document and weren't doing that when both DOMs (source and target) were initially built by a parser.
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Chad La Joie <laj...@itumi.biz> wrote on 06/02/2010 08:26:32 AM: > Okay, bug with test case submitted: > > https://issues.apache.org/jira/browse/XERCESJ-1450 > > On 5/31/10 6:24 PM, Michael Glavassevich wrote: > > Hi Chad, > > > > I believe you've found a bug. There have been problems in the past with > > transferring deferred nodes from one document to another through > > adoptNode(). Perhaps we missed this scenario. > > > > Can you create a new JIRA issue [1] and a test case which demonstrates > > the problem? > > > > Thanks. > > > > [1] https://issues.apache.org/jira/browse/XERCESJ > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: mrgla...@ca.ibm.com > > E-mail: mrgla...@apache.org > > > > Chad La Joie <laj...@itumi.biz> wrote on 05/31/2010 05:44:56 PM: > > > > > Just a bit more data. If I create a completely new document and adopt > > > all the elements in to the new document all the elements are adopted > > > without a problem. > > > > > > On 5/31/10 4:50 PM, Chad La Joie wrote: > > > > I have some code that takes a number of relatively large (~10MB) XML > > > > documents, extracts various elements and then adopts them in to one of > > > > the documents (i.e. if documents A, B, and C were read in and > > worked on, > > > > all the elements might get adopted into A). > > > > > > > > This works fine for some number of adoptions but eventually I > > always get > > > > the following error: > > > > java.lang.ArrayIndexOutOfBoundsException: 32 > > > > at org.apache.xerces.dom.DeferredDocumentImpl.clearChunkValue (Unknown > > > > Source) > > > > at > > org.apache.xerces.dom.DeferredDocumentImpl.getNodeValueString(Unknown > > > > Source) > > > > at > > org.apache.xerces.dom.DeferredDocumentImpl.getNodeValueString(Unknown > > > > Source) > > > > at org.apache.xerces.dom.DeferredTextImpl.synchronizeData(Unknown > > Source) > > > > at org.apache.xerces.dom.NodeImpl.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ParentNode.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ElementImpl.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ParentNode.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ElementImpl.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ParentNode.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.ElementImpl.setOwnerDocument(Unknown Source) > > > > at org.apache.xerces.dom.CoreDocumentImpl.adoptNode(Unknown Source) > > > > > > > > I can't see anything special or unique about the element that is being > > > > adopted when the error occurs. It pretty much looks like every other > > > > element that gets adopted. Given the same order of elements to be > > > > adopted the error always occurs one the same element. Changes in the > > > > ordering cause more or fewer elements to be adopted. This makes me > > > > wonder if the issue is an internal buffer somewhere that isn't growing > > > > appropriately. > > > > > > > > Has anyone run in to this before? > > > > > > > > Thanks. > > > > > > > > > > -- > > > Chad La Joie > > > http://itumi.biz > > > trusted identities, delivered > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > > > For additional commands, e-mail: j-users-h...@xerces.apache.org > > > > -- > Chad La Joie > http://itumi.biz > trusted identities, delivered > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org
