RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

[huizhe wang]

Hi Christoph,

Refer to the previous email, I know we discussed your customer's need to 
process legacy sources. However, Xalan inherently requires namespace 
aware. I also don't think adding a SAX feature to the Transform API is 
appropriate.

Thanks,
Joe

On 1/18/2017 8:44 AM, Langer, Christoph wrote:
> Hi,
>
> I have created a new webrev for this enhancement:
> http://cr.openjdk.java.net/~clanger/webrevs/8023653.1/
>
> As it bases on the change proposal for the new bug 8172974 [1], it is much smaller and really only contains the modifications needed for honoring the feature "namespace-aware" on TransformerFactory.
>
> As to your comments, Joe: I can't just use JdkXmlUtils.setXMLReaderPropertyIfSupport, as this one is a feature. So I added a JdkXmlUtils.setXMLReaderFeatureIfSupport. Is that what you want?
>
> The test was already improved in the webrev for 8172974 [2], I just add two more scenarios for StreamSources on Transformers with "namespace-aware == false".
>
> I would certainly also need help from someone in Oracle to run me through the ccc process, as this probably is a behavioral change for TransformerFactory.
>
> Thanks & Best regards
> Christoph
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8172974
> [2] http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>
>
>
>> -----Original Message-----
>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
>> Sent: Samstag, 19. November 2016 01:50
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8023653: xalan inconsistently parses DOMSource and
>> StreamSource
>>
>> Hi Christoph,
>>
>> XMLReaderManager, 175 - 186 can be replace with:
>>           JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
>> NAMESPACES_FEATURE, m_NamespaceAware, false);
>>           JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
>> NAMESPACE_PREFIXES_FEATURE, !m_NamespaceAware, false);
>>
>>
>> The new test can be improved:
>>       Test all 4 source types
>>       Use a dataprovider (with data fields: Source, Transformer or
>> NamespaceAware, Expected String, etc)
>>       Test also Templates to verify the namespace feature is propagated
>> properly
>>
>> Thanks,
>> Joe
>>
>> On 11/17/16, 9:14 PM, Joe Wang wrote:
>>> Together with 8169631, I think we need to understand your customer's
>>> requirement before spending time on a change that would otherwise be
>>> unnecesary. Why would turning off namespace-aware help him? As far as
>>> the xml standards and parser/processor are concerned, it's a backward
>>> development. A namespace-aware parser is compatible with the ones that
>>> don't know about namespaces. The norm then is to always turn it on
>>> (although the API had to default to off because of the legacy). Is the
>>> user processing some legacy xml code?
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 11/16/16, 5:41 AM, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> to address the long standing bug 8023653 I propose the following change:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023653
>>>>
>>>> I think the bug report in general complains that the default for
>>>> DOMSource input is to parse the input "namespace-unaware" whereas, if
>>>> XALAN gets a StreamSource as input, it is parsed "namespace-aware".
>>>>
>>>> Generally I'm against changing either of these defaults (at this time
>>>> at least) - XALAN StreamSource should be handled namespace aware and
>>>> changing the default for DocumentBuilderFactory is maybe an option
>>>> for the Java 10 timeframe, I'd  say. However, at the moment it is not
>>>> possible at all to configure XALAN's handling of StreamSource input
>>>> to be namespace unaware. That's what I'd like to address with my
>>>> change. With my modifications it's possible to set the namespace
>>>> feature on the TransformerFactory (to false). It bases on my other
>>>> open fix 8169631 which is discussed here:
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
>> November/044662.html
>>>> Only with the corrections for that fix, the SAX parsing that is used
>>>> for stream sources will be handled correctly.
>>>>
>>>> The proposed change from the bugreport (change options for the parser
>>>> of the XSL input before compilation) would not help with the reported
>>>> issue and also is not a good idea anyway as xsl input needs to be
>>>> handled with namespaces obviously.
>>>>
>>>> I did other cleanups in my change as well, the real functional
>>>> changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and
>>>> XMLReaderManager.java.
>>>>
>>>> Thanks in advance for reviewing.
>>>>
>>>> Best regards
>>>> Christoph
>>>>