Hi Joe, thanks for looking.
Can you let me know which smoke test is failing? I didn't see issues so far - I was merely running the jtreg unittests for transformer. I stepped back from replacing Vector with ArrayList for m_prefixMappings because the code is using methods indexOf() with a start index and setSize() for which ArrayList has no direct matchings. One could, for sure, add some other coding, e.g. use ArrayList's subList() method for the index based search - but I wouldn't want to run the risk of adding a regression here just because I modified the code and did not well test it. But if you insist, I could have another look. Best regards Christoph > -----Original Message----- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Sent: Dienstag, 15. November 2016 03:23 > To: Langer, Christoph <christoph.lan...@sap.com> > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via > namespace-unaware SAX input yields a different result than namespace- > unaware DOM input > > Hi Christoph, > > Not all tests have finished yet, but there's at least one failure in the > smoke test. I'll get to the details when I have time. > > Any reason why m_prefixMappings can not be replaced with ArrayList? > > Thanks, > Joe > > On 11/14/16, 6:10 AM, Langer, Christoph wrote: > > Hi, > > > > please review this fix for bug 8169631. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ > > > > When XALAN is handling namespace unaware input, it behaves differently > while using SAX input compared to DOM input. > > > > With both input source types, the class > com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX > input into a DTM representation for processing by the XALAN transformer. Its > method startElement takes URI, localname and qName as attribute. In case of > missing feature namespaces, startElement and localname can be empty. > However, the function uses the localname value for the call to > m_expandedNameTable.getExpandedTypeID() and further processing. In the > case where only qName has data, this leads to issues. > > > > When using DOM input, the class > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM input > into SAX input. In the case of empty localname, it fills localname with qname > data. See method getLocalName() [1], called by parse() [2]. > > When directly using SAX input, the SAX parser calls the startElement() > function on XALAN's handler with empty uri and localname - which seems > correct, as per the spec. > > > > Both paths end up in SAX2DTM2's startElement(). So I suggest to change this > method to handle the case when uri and localname are empty and then set > qname as localname. Maybe one should even change DOM2SAX's > getLocalName handling to not fill localname with qname in case it is empty > after SAX2DTM was changed.. > > > > Generally, JavaDoc for SAXSource says that "Attempting to transform an input > source that is not generated with a namespace-aware parser may result in > errors." But why not fix some of these :) > > > > Furthermore I did some cleanups in the code. > > > > Thanks and best regards > > Christoph > > > > [1] > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 > > [2] > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 > > [3] > https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource > .html > > > >