On Mar 6, 2013, at 1:28 PM, David Karlsen <[email protected]> wrote:
> 2013/3/6 Daniel Kulp <[email protected]>: >> >> On Feb 27, 2013, at 1:17 PM, 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. >> >> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
