cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-4114) Better support for backward compatiability (by default)
Date Thu, 07 Mar 2013 17:39:11 GMT

     [ https://issues.apache.org/jira/browse/CXF-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Kulp resolved CXF-4114.
------------------------------

       Resolution: Won't Fix
    Fix Version/s: Invalid
         Assignee: Daniel Kulp


Had a discussion about this on the list:

http://mail-archives.apache.org/mod_mbox/cxf-users/201303.mbox/%3C92741DEC-8A35-4187-91D1-D14F133837DD%40apache.org%3E
                
> Better support for backward compatiability (by default)
> -------------------------------------------------------
>
>                 Key: CXF-4114
>                 URL: https://issues.apache.org/jira/browse/CXF-4114
>             Project: CXF
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.3.9, 2.4.6, 2.5.2
>            Reporter: Rouble
>            Assignee: Daniel Kulp
>             Fix For: Invalid
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> Consider the situation where a CXF Web Service is released with a certain set of operations
and input/output data beans. Lets call this Web service version 1.0. Third parties write CXF
clients against the CXF Web Service version 1.0 we'll call these 1.0 CXF clients.
> Now, in the next release of the CXF Web Service (say 1.1), one attribute in one input
data bean is removed from the web service. This is widely considered to be backwards compatible
operation.
> Any 1.0 CXF clients, will still send that field when communicating with a 1.1 CXF web
service - and the web service will throw an unmarshallexception. A seemingly innocuous action
of removing an attribute from an input data bean causes the service to stop working for older
clients.
> Now, there is a workaround in CXF today. By setting set-jaxb-validation-event-handler
to false, you can avoid the JAXB validation checks. This is done as follows:
>   <jaxws:endpoint id="foo_v1_0" 
>                   address="/v1_0//foo" 
>                   implementor="com.example.fooImpl"> 
>         <jaxws:properties>
>             <entry key="set-jaxb-validation-event-handler" value="false" />
>         </jaxws:properties>
>     </jaxws:endpoint>
> However, this turns off *all* JAXB validation. That is not desirable for services. The
services should not have to choose between backwards compatibility and disabling all JAXB
validation.
> So, this enhancement is requesting for a new property, something like "set-jaxb-ignore-additional-fields"
- which only ignored additional fields and does not require services to disable all JAXB validation.

> Further, this enhancement is requesting that the default for this property be "true"
- so that by default a CXF web service will ignore additional fields in a SOAP request. This
enhancement will take CXF one step closer to supporting backwards compatibility out of the
box - and thus make it more developer friendly.
> Lastly, but importantly, this requirement also applies to clients. In our example, if
the CXF Web Service version 1.1 added a field to an output data bean, then any 1.0 CXF clients
should (by default) not throw an unmarshal exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message