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

[Joe Wang]

On 11/14/16, 11:43 PM, Langer, Christoph wrote:

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 sent the test to your mailbox.

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.

Ok, that's fine. subList would do, but setSize may need a bit more work.

Best,
Joe

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