Unmarshal Error - CXF 2.1.6 vs CXF 2.2.4

[jbradfor <jb...@amfam.com>]

We use CXF for Providers and Consumers here. 

We added a single optional element to a complex type (2.2.4), regened and
deployed our Provider. 

All Consumers who are running 2.1.6 continue on without errors or incidents. 

All Consumers who are running 2.2.4 started blowing up with UnMarshal
errors, not recognizing the new Optional element. 

Why is this, and is there any workaround? 

This puts a real big slow down in our development process, since we have to
create a new MAJOR version (essentially a whole new service), versus making
our contract backward compatible. 
-- 
View this message in context: http://cxf.547215.n5.nabble.com/Unmarshal-Error-CXF-2-1-6-vs-CXF-2-2-4-tp2799836p2799836.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Unmarshal Error - CXF 2.1.6 vs CXF 2.2.4

[jbradfor <jb...@amfam.com>]

Thanks Dan, that answers it.

Jeff
-- 
View this message in context: http://cxf.547215.n5.nabble.com/Unmarshal-Error-CXF-2-1-6-vs-CXF-2-2-4-tp2799836p2799875.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Unmarshal Error - CXF 2.1.6 vs CXF 2.2.4

[Daniel Kulp <dk...@apache.org>]

On Wednesday 01 September 2010 4:33:36 pm jbradfor wrote:
> We use CXF for Providers and Consumers here.
> 
> We added a single optional element to a complex type (2.2.4), regened and
> deployed our Provider.
> 
> All Consumers who are running 2.1.6 continue on without errors or
> incidents.
> 
> All Consumers who are running 2.2.4 started blowing up with UnMarshal
> errors, not recognizing the new Optional element.

> Why is this, and is there any workaround?

I'll start with the second part of that:
You can configure the 2.2.4 consumers with a property of 
"set-jaxb-validation-event-handler" with a value of "false" and it would 
ignore any unknown elements that are sent on the wire.  That's pretty much the 
2.1.6 behavior.

For the first part of the question:
The 2.2.4 behavior is more "correct".   The schema that was used to generate 
those clients did not allow for the constructs to be extended by adding 
additional elements.   According to the contract it used, there should not be 
any additional elements in the sequences.   Thus, when it encounters unknown 
information, it needs to throw an exception.   An optional element is optional 
in a sense that it doesn't need to be there, but if it is there, it does need 
to be understood.  

If you want your schemas to be extensible in the future, you would need to add 
something like:

<xsd:any/> 

to the bottom of the structures to act as a placeholder for any new elements 
that may be placed later.   

ALTERNATIVELY, on the Provider side, you could try and detect the version of 
the client via some method (like maybe a header passed in or some field on an 
input object or something) and just not fill in the data of the optional 
elements if it's an older client.

> This puts a real big slow down in our development process, since we have to
> create a new MAJOR version (essentially a whole new service), versus making
> our contract backward compatible.

Adding an optional element is not a backward compatible change for returned 
data.  For incoming data, it is, but not outgoing data.   The older clients 
would not send that data which is fine, but they also won't understand that 
optional data if you return it.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog