cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rouble <>
Subject Re: CXF Schema Validation Heartburn
Date Wed, 27 Feb 2013 18:17:02 GMT
Apologies for the late reply. I did not see this response earlier.

Throwing an error on unexpected elements breaks backwards
compatibility as well. For example, say you have a service version 1.0
with an api getFoo() which returns Foo. Foo has one field 'bar'. Now,
your service becomes wildly successful and many companies write
clients against your service. In version 2.0 you had another field,
'foobar' to Foo. Now all those previously written clients will break
and throw an exception when they receive Foo. I think the default
behavior should always be to be lenient and accept fields you do not
know and care about.

The main reason for my thread was that default behavior of CXF seems
odd. In some cases it is strict by default, like when it detects
unexpected elements. And then in other cases, like for @Required, it
is lenient, and does no checking by default! This almost feels

Also for misspelled enums CXF silently accepts them - with no
indication to the service or the client what happened.

I will file JIRAs for each one of the cases I mentioned below, so they
are tracked. The authors can discuss or close them as needed. I can
also attach test cases with the latest CXF version.


On Thu, Nov 15, 2012 at 2:31 AM, Jason Pell <> wrote:
> First of all you really should not be basing your investigation on such an
> old and unsupported version of cxf. We are up to 2.7.0.
> Also I disagree on your forwards compatibility statement. In my experience
> with web service interface design you design for backwards compatibility
> not the other way around.
> Anyway feel free to review 2.7.0 and I am sure we can figure some of this
> out. However some of if not most of your issues are probably going to be
> limitations or design choices in jaxb and jaxws.
> For instance required is a jaxb annotation and only validated if you enable
> schema validation.
> Perhaps it might be possible to configure subsets of what is validated
> rather than validate everything.
> Happy to discuss further and review assist with any contributions you might
> want to make.
> Feel free to open a enhancement jira I would not consider the current
> behavior to be a bug.
> Other committers might disagree with me.
> Sent from my Galaxy S2
> On Nov 15, 2012 7:57 AM, "rouble" <> wrote:
>> 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
>> case.
>> *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.
>> tia
>> Rouble

View raw message