Hi, >From what I could work out, from within the list comments and the code, the state is stored in the Document itself, and as cloneNode uses Object.clone and then sets the doc it won't work. Using importNode helps a little (as it uses getFirstChild()/getNextSibling()), but it just puts the problem to a later stage.
getAllElements just does the same, calls getChildNodes and then forces the cache to be used. Deleting the cache just stops the null for the parent, it doesn't stop incorrect nodes being returned or race conditions with other nulls. The simple thing is to stop using getChildNodes, from what I can see in the code there isn't a need for it. The only place I've seen that doesn't require all of the nodes anyway is in EndpointReference's getNumberOfParameters, but that behaviour can be safely cached (its not used directly in the project anyway). Looking further at the use cases in Muse only the IsolationLayer (because of the DeferredImpl) needs to call hasChildNodes() on the document node, for it to force that synchronizeChildren be called (its cached from then on in each node). Then every other piece of code can simply pointer chase with the getFirstChild()/getNextSibling() approach. No synchronization required. re using other jaxp's, the DOM itself makes no statement about even read thread safety. All of the jaxp impls suffer some form of threading problem. Considering all of the problems with fighting against namespace problems (much worse IMO) it makes sense to stick with the devil you know :-<. Again for most of the xerces releases using the getFirstChild()/getNextSibling() is a seamless dropin for the getChildNodes problem. Its a shame that the xerces guys are very much against any form of thread safety (except application enforced). Going with the standard approach the only safe thing is to always serialize to objects / keep the strings around, which would overly complicate the code. I'm willing to give it a try and send you patched libs to try out (I don't have a test case for this yet) if its quick to reproduce, just let me know. If it works out I can raise a jira with the patches. cheers, Chris PS(this problem is a very unpleasent suprise for me, I've been caching Documents in another application which can then be used in jaxp transformations and xalan uses the getChildNodes approach in a few places. Now I see its only been working by luck alone :-< ). -----Original Message----- From: dnguyen [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 6:46 PM To: [email protected] Subject: RE: EndpointReference thread-safe? Hi, After some digging a good while back, we found that Xerces optimized the processing by using caching. Tracing through the Xerces source, we discovered that the cache was being deleted after the thread finished processing or parsing the DOM object, thus invalidating the current "state" of the DOM object for other threads that may be in the middle of processing. It also seemed that even if you make a "deep" copy of the DOM object, they would share the same cache (not sure)? We hacked org.apache.xerces.dom.ParentNode to instead not delete this cache. This got us around the NullPointerException due to invoking toXML() on the producer EPR in SimpleNotificationMessage.toXML(), but we ran across another NullPointerException further down the source at XmlUtils.getAllNamespaces(root). The stacktrace ends at XmlUtils.getAllElements(). At that point, we have given up. The question now is could another JAXP library be easily substituted for Xerces? Dong --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
