cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rouble <>
Subject CXF Schema Validation Heartburn
Date Wed, 14 Nov 2012 20:55:49 GMT
CXF Gurus,

I am documenting some of the major inconsistencies we have noticed with CXF
with respect to Schema Validation.
These findings are based on CXF 2.4.3, for java first web services. If
anyone has suggestions on how to address
some of these validation concerns please let me know - but as far as we can
tell there are some holes.

First, let me state that there are two ways developers can validate schema
in CXF. First by enabling schema validation:
*             <entry key="schema-validation-enabled" value="true"/>*

And secondly by inserting a custom validation event handler:
*             <entry key="jaxb-validation-event-handler">
                 <bean class= "com.example.MyValidationEventHandler" />
            </entry> *

Here are the issues:
*1) By default, CXF will throw an error if it sees an unexpected element*
    This is a poor choice because interfaces are more "forwards compliant"
if they can support unexpected elements.
    Many protocols, SIP, HTTP, etc. recommend that clients and servers be
lenient on what they can accept, and ignore
    unexpected elements - for this very reason.

   * Solution:*
    To configure a CXF WS to accept unexpected elements, one can write a
custom validation handler that implements
    ValidationEventHandler, and ignore an "unexpected element" errors.

    Note: If you have schema validation enabled, then it will throw an
"unexpected element" error AND it will throw an
    cvc-complex-type.2.4.d error. This becomes an issue for the next use

*2) By default, CXF will not honor minOccurs=1*
    If we have fields marked with @Required, CXF will not police the
presence of that required field.
    Again, this is probably something that should probably be handled by
default in a vanilla CXF web service.

   * Solution:*
    Enforcement of required fields can be enabled by enabling Schema
Validation, but there is a catch. First enabling
    schema validation  degrades performance but secondly, and more
importantly, the same error is thrown in the
    ValidationEventHandler: cvc-complex-type.2.4.d, as is thrown for
unexpected elements!

    To accept unexpected elements we need to ignore cvc-complex-type.2.4.d,
but to police minOccurs=1, we need
    to throw an error on cvc-complex-type.2.4.d in our custom
ValidationEventHandler. This is not possible.

    As far as we can tell, there is no way to support minOccurs=1, and
accept unexpected elements. So developers have
    to choose between one or the other - this is not ideal - and seems to
be a hole.

*3) By default, CXF will accept a misspelled enum value - but (silently)
set the corresponding field to null*
    Once again this is one that should by default throw an error.
Unsuspecting developers have no way of knowing whether
    the null as really a null value, or if the enum value was misspelled.

   * Solution:*
    This can be fixed by enabling schema validation - but that has
performance implications. The default behavior of CXF can
    catch developers by surprise.

To summarize, CXF _must_ send unique errors for different protocol
violations to be usable, but also CXF should probably
have better default behavior for some of these listed use cases. Let me
know if I should file a defect.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message