RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

[Langer, Christoph]

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.wang at oracle.com]
> Sent: Dienstag, 15. November 2016 03:23
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at 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
> >
> >