This will not work if you set  "Defered node expansion" to False because 
in the  NodeList implementation will still do the caching and there will 
be problem in that.I have tested that.  So you really do not have any 
other option but to use this like of implementation.

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/26/2007 11:49 AM
Please respond to
[EMAIL PROTECTED]


To
Soumya Chatterjee <[EMAIL PROTECTED]>, j-users@xerces.apache.org
cc

Subject
Re: Got the Issue






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

ForwardSourceID:NT00009C12 
=====-----=====-----=====
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


Reply via email to