Test cases are always a way to fast track your issues Sent from my Galaxy S2 On Feb 28, 2013 5:18 AM, "rouble" <[email protected]> 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 <[email protected]> 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" <[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 > >> >
