You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by rouble <r....@gmail.com> on 2012/11/14 21:55:49 UTC
CXF Schema Validation Heartburn
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
Re: CXF Schema Validation Heartburn
Posted by Jason Pell <jp...@apache.org>.
Test cases are always a way to fast track your issues
Sent from my Galaxy S2
On Feb 28, 2013 5:18 AM, "rouble" <r....@gmail.com> wrote:
> 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
> backwards.
>
> 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.
>
> tia,
> rouble
>
> On Thu, Nov 15, 2012 at 2:31 AM, Jason Pell <jp...@apache.org> 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" <r....@gmail.com> 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
> >>
>
Re: CXF Schema Validation Heartburn
Posted by Daniel Kulp <dk...@apache.org>.
On Mar 6, 2013, at 1:28 PM, David Karlsen <da...@gmail.com> wrote:
> 2013/3/6 Daniel Kulp <dk...@apache.org>:
>>
>> On Feb 27, 2013, at 1:17 PM, rouble <r....@gmail.com> wrote:
>>
>>> 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.
>>
>> We had this behavior as the default for a while and it became a LARGE support burden. We had many many problems of people reporting that CXF wasn't deserializing things correctly and all their incoming properties and such were null. The main reason was they had the namespace wrong or the element names slightly wrong or something which made them become "unknown" elements that were then ignored. This is not something I would change back to as a default. If something is unexpected, an error should be raised so the user knows to look at it.
>
> I second that. If you really want to be lenient - design the schemas
> to be lenient (using xsd:any elements in the end of a sequence, using
> xsd:all etc). But this is no easy task. Generally creating new
> versions (with unique namespaces) of a service is the bulletproof
> solution - but with the additional burden of having more services.
The OTHER way I've seen this done without using new namespaces and such is to include a "version" into the request somehow. (soap header, maybe a field on the request object). The service would then look at that and just not fill in the elements that were not appropriate for that version. If it sees a "version 1" request, it would respond with a response only filling in details applicable to that version. If it sees a version 2, it fills in everything. Not perfect, but I've seen it work. Puts the burden on the service writer to make sure the responses are correct for the callee.
>>> 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
>>> backwards.
>>
>> It kind of depends on what can be checked without any performance impact. The "default" is basically the stuff that can be done without affecting performance. With unexpected elements, JAXB only calls the handler whenever it detects one so there is no impact at all for the cases where they aren't encountered. For the "required" stuff, some sort of post processing to check for the required would need to be done which could slow things down. (and generally, you might as well do full schema validation in that case)
>>
>>> Also for misspelled enums CXF silently accepts them - with no
>>> indication to the service or the client what happened.
>>
>> Hmm.. That would be a JAXB issue as well. I'd need to see if JAXB calls off to a handler for this or not. Interesting. I'd consider this a bug, but it might be completely within JAXB and nothing we could do about it (other than log a bug with them).
>
> Mmm - I think this might be a misconception.
> The thing is that the jaxb generated code will contain only some of
> the metadata used for validation. For full validation adhering to the
> schema you need to configure your jax-ws/cxf endpoints with the .wsdl
> as well as the servicename and so on - only in these cases are the
> full schema definition found and properly validated.
>
> If you simply configure the endpoint with validation turned on, but
> miss to refer the wsdl then the complete validation will not be
> performed because JAXB only has the generated code containing the jaxb
> annotations - and this is inadequate.
>
> Examples for this is enums (as far as I remember) - and certainly for regexes
Well, yea. Full validation is definitely preferred, but there is a performance impact with that. In theory, when JAXB calls "EnumClass.valueOf(incomingString)", an exception is thrown if the string doesn't match something. Very similar to the unknown element cases. JAXB is hopefully calling the handler to let the handler deal with that. If so, this is again a "0 performance impact" type check that we could/should be doing to let the user know the incoming data is not usable without the full schema validation impact.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF Schema Validation Heartburn
Posted by David Karlsen <da...@gmail.com>.
2013/3/6 Daniel Kulp <dk...@apache.org>:
>
> On Feb 27, 2013, at 1:17 PM, rouble <r....@gmail.com> wrote:
>
>> 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.
>
> We had this behavior as the default for a while and it became a LARGE support burden. We had many many problems of people reporting that CXF wasn't deserializing things correctly and all their incoming properties and such were null. The main reason was they had the namespace wrong or the element names slightly wrong or something which made them become "unknown" elements that were then ignored. This is not something I would change back to as a default. If something is unexpected, an error should be raised so the user knows to look at it.
I second that. If you really want to be lenient - design the schemas
to be lenient (using xsd:any elements in the end of a sequence, using
xsd:all etc). But this is no easy task. Generally creating new
versions (with unique namespaces) of a service is the bulletproof
solution - but with the additional burden of having more services.
>
>> 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
>> backwards.
>
> It kind of depends on what can be checked without any performance impact. The "default" is basically the stuff that can be done without affecting performance. With unexpected elements, JAXB only calls the handler whenever it detects one so there is no impact at all for the cases where they aren't encountered. For the "required" stuff, some sort of post processing to check for the required would need to be done which could slow things down. (and generally, you might as well do full schema validation in that case)
>
>> Also for misspelled enums CXF silently accepts them - with no
>> indication to the service or the client what happened.
>
> Hmm.. That would be a JAXB issue as well. I'd need to see if JAXB calls off to a handler for this or not. Interesting. I'd consider this a bug, but it might be completely within JAXB and nothing we could do about it (other than log a bug with them).
Mmm - I think this might be a misconception.
The thing is that the jaxb generated code will contain only some of
the metadata used for validation. For full validation adhering to the
schema you need to configure your jax-ws/cxf endpoints with the .wsdl
as well as the servicename and so on - only in these cases are the
full schema definition found and properly validated.
If you simply configure the endpoint with validation turned on, but
miss to refer the wsdl then the complete validation will not be
performed because JAXB only has the generated code containing the jaxb
annotations - and this is inadequate.
Examples for this is enums (as far as I remember) - and certainly for regexes.
>
> Dan
>
>
>> 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.
>>
>> tia,
>> rouble
>>
>> On Thu, Nov 15, 2012 at 2:31 AM, Jason Pell <jp...@apache.org> 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" <r....@gmail.com> 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
>>>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: CXF Schema Validation Heartburn
Posted by Daniel Kulp <dk...@apache.org>.
On Feb 27, 2013, at 1:17 PM, rouble <r....@gmail.com> wrote:
> 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.
We had this behavior as the default for a while and it became a LARGE support burden. We had many many problems of people reporting that CXF wasn't deserializing things correctly and all their incoming properties and such were null. The main reason was they had the namespace wrong or the element names slightly wrong or something which made them become "unknown" elements that were then ignored. This is not something I would change back to as a default. If something is unexpected, an error should be raised so the user knows to look at it.
> 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
> backwards.
It kind of depends on what can be checked without any performance impact. The "default" is basically the stuff that can be done without affecting performance. With unexpected elements, JAXB only calls the handler whenever it detects one so there is no impact at all for the cases where they aren't encountered. For the "required" stuff, some sort of post processing to check for the required would need to be done which could slow things down. (and generally, you might as well do full schema validation in that case)
> Also for misspelled enums CXF silently accepts them - with no
> indication to the service or the client what happened.
Hmm.. That would be a JAXB issue as well. I'd need to see if JAXB calls off to a handler for this or not. Interesting. I'd consider this a bug, but it might be completely within JAXB and nothing we could do about it (other than log a bug with them).
Dan
> 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.
>
> tia,
> rouble
>
> On Thu, Nov 15, 2012 at 2:31 AM, Jason Pell <jp...@apache.org> 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" <r....@gmail.com> 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
>>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF Schema Validation Heartburn
Posted by rouble <r....@gmail.com>.
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
backwards.
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.
tia,
rouble
On Thu, Nov 15, 2012 at 2:31 AM, Jason Pell <jp...@apache.org> 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" <r....@gmail.com> 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
>>
Re: CXF Schema Validation Heartburn
Posted by Jason Pell <jp...@apache.org>.
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" <r....@gmail.com> 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
>