Like someone else suggested earlier have you tried turning off the
Defered node expansion to see if you still face any problems ?
Try :
docBuilderFactory.setAttribute("http://apache.org/xml/features/dom/defer-node-expansion";,
Boolean.FALSE);
Be adviced that turning this feature off will mean your code (even if it
works) will have a semantic-lock in to behavior of Xerces XML parser.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=27687
I am not sure fixing the parser to become thread-safe when it is already
declared to be not a goal is such a good idea. Besides there may be
other places in the xerces code where assumption of no concurrent access
may be made.
-Prashant
On Thu, 2007-07-26 at 11:38 +0530, Soumya Chatterjee wrote:
>
> The NodeList implementation is not thread safe. When iterating through
> children of a particular node, the NodeList gets changed by another
> thread doing the same action. As a result I get a NullPointerException
> sometimes and some other times I get "wrong document error" when I try
> to append this clone a child node to a document. We can see the
> following links for that.
>
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200403.mbox/%
> [EMAIL PROTECTED]
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=27687
>
> The first implementation to access children of a node does not work.
> NodeList childList=root.getChildNodes();
> for (int i=0; i<childList.getLength(); i++)
> {
> // doing something here with "childList.item(i)"
> }
>
>
> The second implementation to access children of a node works.
> Node currChildNode = root.getFirstChild();
> while(currChildNode != null)
> {
> // Do something here with the "currChildNode"
> currChildNode = currChildNode.getNextSibling();
> }
>
> Thanks,
> Soumya Chatterjee
> Tata Consultancy Services
> Mailto: [EMAIL PROTECTED]
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Outsourcing
> ____________________________________________
>
>
> Prashant Reddy
> <[EMAIL PROTECTED]>
>
> 07/25/2007 06:20 PM
> Please respond to
> [EMAIL PROTECTED]
>
>
>
>
> To
> j-users@xerces.apache.org
> cc
> Soumya Chatterjee
> <[EMAIL PROTECTED]>
> Subject
> Re: Got the Issue
>
>
>
>
>
>
>
>
> On Wed, 2007-07-25 at 11:58 +0530, Soumya Chatterjee wrote:
> >
> > Hi Michael,
> >
> > Do you think SAX is a good alternative for the DOM in this case. We
> > can migrate the parsing mechanism to SAX if there is no thread safe
> > issue in SAX parser.
>
> SAX will help you build custom Data model for the XML it is parsing.
> Usually SAX parsing of XML file is done only once (inside a method) to
> construct the Data model. It is *not* a good idea to start a SAX
> parser
> every time you would like to read something from the XML. (if thats
> what
> you were hinting at in your question above)
>
> You could think of DOM as a "generic" Data model that works for all
> XMLs. While using DOM every thing is a Node/Element/Text Node and you
> lose out on type safety and domain friendliness a custom Data model
> would offer.
>
> Consider the proverbial purchase order xml[1] for example:
> You could walk this XML with SAX parser and construct Data model like
>
> Class PurchaseOrder {
> Address getShippingAddress();
> Address getBillingAddress();
> List<Item> getItemsOrdered();
> String getComment();
> } //Notice there are not setters
>
> Where if you were to make DOM of the same XML, you would have to walk
> NodeList list = purchaseOrderNode.getChildNodes(); //This is not
> thread
> safe
>
> Now is it a good alternative to DOM ?
>
> The answer would depend as always on your use-cases. An immutable Data
> object is as thread safe as it can get. And if you are accesses to XML
> are read only, constructing a Data model from SAX parsing is worth
> considering.
>
> Hope this helps
> -Prashant
>
> [1] : http://www.w3.org/TR/xmlschema-0/#po.xml
> PS: While you are at exploring options, you could also give JAXB a
> look
> see.
> > Thanks,
> > Soumya Chatterjee
> > Tata Consultancy Services
> > Mailto: [EMAIL PROTECTED]
> > Website: http://www.tcs.com
> > ____________________________________________
> > Experience certainty. IT Services
> > Business Solutions
> > Outsourcing
> > ____________________________________________
> >
> >
> > Michael Glavassevich
> > <[EMAIL PROTECTED]>
> >
> > 07/24/2007 07:27 PM
> >
> >
> > To
> > Soumya Chatterjee
> > <[EMAIL PROTECTED]>
> > cc
> > j-users@xerces.apache.org
> > Subject
> > Re: Got the Issue
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Soumya,
> >
> > Xerces' DOM implementation isn't thread-safe. If you try to access
> > the
> > same DOM instance from multiple threads without synchronizing it
> > you'll
> > run into these problems. You either need to synchronize your code
> or
> > create an instance of the DOM tree per thread. There's really no
> way
> > around it.
> >
> > Thanks.
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: [EMAIL PROTECTED]
> > E-mail: [EMAIL PROTECTED]
> >
> > Soumya Chatterjee <[EMAIL PROTECTED]> wrote on 07/24/2007
> > 09:42:08
> > AM:
> >
> > > Hi Michael,
> > >
> > > I found out the response from you regarding the "xerces DOM
> > > concurrent access" and I think it is the same as our application
> in
> > > the case. http://spteam-lists.blogspot.com/2007/04/re-xerces-dom-
> > > concurrent-access-and.html
> > >
> > > By the way we were not getting the exception as frequently in
> the
> > > weblogic 7.1 ( JDK 1.3) when we are using the following Xerces.
> > >
> > > But we are getting the exception in case of weblogic 9.1 much
> more
> > > frequently which uses JDK1.5 and different version of Xerces.
> > >
> > > Synchronization is not an option in this case because there is a
> > > huge performance issue here. Please let me know if any way we can
> > > get read of this problem without using the Synchronization
> block.
> > >
> > > Thanks,
> > > Soumya Chatterjee
> > > Tata Consultancy Services
> > > Mailto: [EMAIL PROTECTED]
> > > Website: http://www.tcs.com
> > > ____________________________________________
> > > Experience certainty. IT Services
> > > Business Solutions
> > > Outsourcing
> > > ____________________________________________
> >
> > ForwardSourceID:NT00009A82
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> --
>
> -Prashant
>
> Don't upload, just share : www.dekoh.com
>
> ForwardSourceID:NT00009B6E
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
--
-Prashant
Don't upload, just share : www.dekoh.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
