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
