2.3 Migration Guide

New features

• New annotations of java first use cases
  • @WSDLDocumentation annotation to add documentation nodes to generated wsdl
  • @SchemaValidation annotation to turn on schema validation
  • @DataBinding to set the databinding used (if other than JAXB)
  • @GZIP to turn on GZIP compression
  • @FastInfoset to turn on FastInfoset support
  • @Logging to turn on and control various Logging functionality
  • @EndpointProperty to configure endpoint properties
  • @Policy to associate WS-Policy documents with the service
• SOAP/JMS spec implementation
• SDO databinding
• JAX-WS 2.2 Support
• JAX-RS 1.1 Support

API changes

• As part of cleaning up the API's and use of generics in the API's, the InterceptorProvider API changed it's methods from:

  List<Interceptor> getOutInterceptors();
  

  to

  List<Interceptor<? extends Message>> getOutInterceptors();
  

  While binary compatible (type erasure makes the raw signatures the same), it's not SOURCE compatible as you may need to update the types of variables used to hold the lists. Generally, just do the same change. Add <? extends Message> to the declaration of the Interceptor.

Runtime changes

• In 2.2.x and earlier, mustUnderstand=true headers were sent into the endpoint (in the List<Header>) and only checked after the endpoint is done processing. If the endpoint doesn't process them, only afterword is the mustUnderstand fault raised. With 2.3.x, mustUnderstand=true headers are checked prior to dispatch. If an endpoint requires mustUnderstand headers to be passed in, it must be configured so the runtime knows to allow them through. To do so, add a endpoint property named "endpoint-processes-headers" that is either a string of the qname of the header to pass in or a collection of string of qnames of headers to pass in. (We'll be adding an annotation or other means to configure this shortly)

• SOAP/JMS - CXF now support the w3c SOAP/JMS spec. Existing SOAP/JMS stuff should continue working, but users are encouraged to start using the standard configurations.

• Provider<Source> and Dispatch<Source> - when specifying a generic "Source" type, CXF now provides a streaming SAXSource object. Previously, CXF would load the whole message into a DOM and provide a DOMSource. Applications that expect a DOMSource will need to be updated to accept the SAXSource or provide configuration to force to DOMSource. There is now a configuration property for the Endpoint of "source-preferred-format" which can be set to:
  • "dom" -> DOMSource
  • "sax" -> SAXSource (cxf StaxSource)
  • "stream" -> StreamSource
  • "cxf.stax" -> StaxSource
  • "stax" -> javax.xml.transform.stax.StAXSource if avail, StaxSource otherwise

• Aegis
  • The set of root classes is now of type Set<java.lang.reflect.Type> to permit generics.
  • The class Type is renamed to AegisType to reduce confusion and conflict with java.lang.reflect.Type.

Config changes