[CXF-6351] Character encoding error in XML schema validation

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.4, 2.7.15
• Fix Version/s: 3.1, 2.7.16, 3.0.5

Environment

JVM using platform default encoding other than UTF-8

• Estimated Complexity: Unknown
• Flags: Patch
• Assignee: Daniel Kulp
• Reporter: Martin Bonato
• Created: 15/Apr/15 11:53
• Updated: 02/Nov/16 08:40
• Resolved: 15/May/15 09:10

Description

I'm using a WSDL with referenced XML schema files containing german umlaut characters. The WSDL and schema files reside in the applications classpath. When XML schema validation is enabled for the corresponding webservice, the schema validation fails if the platform default encoding is not UTF-8 (e.g. ISO-8859-1).

I've created a test case for the issue (tested with CXF 2.7.15) https://github.com/datentechnik/cxf-schema-encoding

When the test case is executed with a -Dfile.encoding=ISO-8859-1 it fails with:

org.apache.cxf.interceptor.Fault: Could not parse the XML stream caused by: javax.xml.stream.XMLStreamException: cvc-enumeration-valid: Value 'm�nnlich' is not facet-valid with respect to enumeration '[männlich, weiblich, unbekannt]'. It must be a value from the enumeration.

The reason is, schema references in WSDL files are read using platform default encoding:

org.apache.cxf.wsdl.EndpointReferenceUtils.SchemaLSResourceResolver

        private LSInputImpl createInput(String newId, byte[] value) {
            LSInputImpl impl = new LSInputImpl();
            impl.setSystemId(newId);
            impl.setBaseURI(newId);
            impl.setCharacterStream(
                new InputStreamReader(
                    new ByteArrayInputStream(value)));
            return impl;
        }

The InputStreamReader uses the default platform character encoding. I would recommend to set the InputStream in LSInputImpl instead of the CharacterStream and let the Schema parser decide on the character encoding.

I've created a pull request https://github.com/apache/cxf/pull/65 which solves the problem (tested with CXF 2.7.x).

I've only tested with the 2.7.x branch, but from the code I think master is affected as well.