[ http://issues.apache.org/jira/browse/XERCESJ-1178?page=comments#action_12429720 ] Michael Glavassevich commented on XERCESJ-1178: -----------------------------------------------
Thanks Hua. I've committed your updates to SVN. A few other comments... > >The other issue is with the AsyncSAXParser thread. It seems like it never > >terminates. I noticed that because the JVM wasn't exiting at the end of my > >test program. I've made it a daemon thread so that the JVM exits but > >there's still a threading problem there. Perhaps the call to the parse > >method on the XMLReader never returns? > > In two cases, the AsyncSAXParser thread will not teminate. > 1) There is an exception occures in the SAXXMLStreamReaderImpl > 2) The user doesn't parse the document to the end > > To make sure the AsyncSAXParser thread terminates correctly, > following modifications are done. > 1) When an exception occurs in the next() method the AsyncSAXParser > thread is interrupted, because after that no call to the > StreamReader is valid. > 2) When an exception occures in other methods of StreamReader, a > call to StreamReader may still be valid, so the AsyncSAXParser > thread shouldn't be interrupted in this case. > 3) In the close() method, if the AsyncSAXParser thread is still > alive, interrupt it. > But if the user doesn't close the StreamReader after using it, the > AsyncSAXParser thread may never terminate. So user should call the > close() method. In my test code I wasn't calling the close() method so it was this last case that was the issue. While I agree that applications should be calling this method they don't have to and if they drop all references to the XMLStreamReader, it and all of its internals should get garbage collected. If the XMLStreamReader gets garbage collected without the AsyncSAXParser thread being terminated it will cause a memory leak because the thread can't be garabage collected until it terminates. A finalize() method should be added to the XMLStreamReader to make sure that the thread gets terminated. > >In the fix that you made in SAXXMLStreamReader.initialElementAttrs() you > >added a check for duplicate attributes that I didn't understand. A SAX > >parser already does this well-formedness check. Is there a reason for > >doing that again in the XMLStreamReader? > > The SAX parser cann't recognize the element such as "<root xmlns: > a='xxx' xmlns:b='xxx' a:attr='1' b:attr='2' />", so I check it myself. All namespace-aware parsers must check this condition [1]. If they don't its a bug. In what case are you seeing this behaviour? [1] http://www.w3.org/TR/xml-names/#uniqAttrs > Error getting prefix for an attribute with no namespace > ------------------------------------------------------- > > Key: XERCESJ-1178 > URL: http://issues.apache.org/jira/browse/XERCESJ-1178 > Project: Xerces2-J > Issue Type: Bug > Components: StAX > Affects Versions: 2.8.0 > Reporter: Lucian Holland > Assigned To: Michael Glavassevich > Attachments: stax_patch_8.19.zip, stax_patch_8.20.zip > > > The initialElementAttrs() method of SAXXMLStreamReader sets the prefix of > attributes to null if it finds no colon in the attribute name; the problem > with this is that getAttributeNamespace() uses this prefix when looking up > the namespace uri with a call to getNamespaceURI on the NamespaceContextImpl, > and this method throws an IllegalArgumentException if null is passed in. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
