cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <jp...@apache.org>
Subject Re: CXF Schema Validation Heartburn
Date Wed, 27 Feb 2013 20:47:26 GMT
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.ouble@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 <jpell@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.ouble@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
> >>
>

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