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" <[email protected]> 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 >
