Markus Schulz created CXF-8979:
----------------------------------
Summary: XML (Woodstox/MSV) based schema validation is broken
Key: CXF-8979
URL: https://issues.apache.org/jira/browse/CXF-8979
Project: CXF
Issue Type: Bug
Affects Versions: 4.0.3, 3.6.2
Reporter: Markus Schulz
Attachments: reproducer.tgz
The current approach to implement the xml schema validation with the Woodstox/
W3CMultiSchemaFactory is unable to validate many schema and returns
false-positive results for them.
The validator is attached on an ({{NUllOutputStream}}-) XMLStreamWriter (see
org/apache/cxf/databinding/source/XMLStreamDataReader.java:231) but this can't
work for abstract elements which needs to be declared explicit thru xsi:type
attribute.
For example the following element:
{code:xml}
<AbstractElement xsi:type="test:STE_ReproducerBasis">Valid1</AbstractElement>
{code}
can't be validate thru this approach because at time of the "StartElement"
validation of the AbstractElement tag (see
_com.ctc.wstx.msv.GenericMsvValidator#validateElementStart_) the {{xsi:type}}
attribute is not known to the current attribute-context and therefore it's not
possible to create the right "ChildAcceptor".
*It returns with an (false-positive) validation error.*
*I've attached an reproducer* which shows an example and that the validation
fails only because it was attached on an writer.
The same xml could be successfully validated if the validator was attached to
the reader instance.
I don't understand the decision why the validator was attached on the writer
and not the reader.
Perhaps someone could give some more details about this and then i could try to
solve this bug by myself (pull-request).
Another point: it looks like there is no way to choose between MSV and the
fallback (schema.newValidator().validate(..)) implementation.
*This leaves me in a problematic situation, i can't explicit switch to the
fallback (which will work).* Perhaps this should be allowed in the fix of this
issue too.
[^reproducer.tgz]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
