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 (see Runtime notes below)
• JAX-RS 1.1 Support
• Schema Validation support for Aegis Databinding if Woodstox 4 is used for the Stax parser
• AtomPub publication of Logging events

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

• To use the new JAX-WS 2.2 and JAXB 2.2 features with Java 6, the jaxws-api and jaxb-api jars need to be endorsed. Otherwise, the runtime and compiler will pick up the 2.1 versions that are built into the JDK. Two common ways to do this is to copy them to your jre/lib/endorsed folder or to add -Djava.endorsed.dirs=... to the command line of your application to point to a directory containing those jars.

• 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. You can use the @EndpointPropery annotation listed above to control this as well.

• 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.

Maven changes

• The XJC utils have been pulled out of the main build and into a separate subproject. From now on, they will be released independently from the rest of CXF and will have their own version numbers. They also were moved into a common "org.apache.cxf.xjcplugins" groupId.