You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Yue Fang (Jira)" <ji...@apache.org> on 2024/11/21 16:22:00 UTC

[jira] [Commented] (CXF-8979) XML (Woodstox/MSV) based schema validation is broken

    [ https://issues.apache.org/jira/browse/CXF-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900113#comment-17900113 ] 

Freeman Yue Fang commented on CXF-8979:
---------------------------------------

Hi [~msc@onesty-tech.de],

Thanks for the reproducer, this helps a lot!

However, I don't think this is a CXF side issue, more like a woodstax/msv side problem. Please see the attached revised SchemaValidationTest.java from which no CXF code gets involved at all, and we can see exactly the same behaviour. Please report this to woodstax/msv community.

Also, I think we can introduce a context property, with it value as "true"(default is false to keep the behaviour as is), we can force to use the fallback schema validator like
{code}
schema.newValidator().validate(new DOMSource(newElement));
{code}

Best Regards
Freeman




> 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: 3.6.2, 4.0.3
>            Reporter: Markus Schulz
>            Assignee: Freeman Yue Fang
>            Priority: Major
>         Attachments: SchemaValidationTest.java, 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)