New Features

  • LogBrowser console
  • Transformation feature provides for a fast and effective way to transform inbound and/or outbound XML messages, please see the TransformationFeature page for more information.
  • JIBX databinding
  • Faster startup and reduced spring configuration. The Spring support has been redone to be based on the ExtensionManagerBus. This results in much faster startup. It also means that all of the imports of META-INF/cxf/cxf-extension-*.xml are no longer needed and are deprecated.
  • WSS4J has been updated from 1.5.x to 1.6. See here (not yet live) for the list of new features and upgrade notes for Apache WSS4J 1.6. Also see Colm's blog for an ongoing list of things that are happening in WSS4J 1.6. Some notable new features for CXF users include:
    • SAML2 support: WSS4J 1.6 includes full support for creating, manipulating and parsing SAML2 assertions, via the Opensaml2 library. See here for more information.
    • Performance work: A general code-rewrite has been done with a focus on improving performance.
    • Support for Crypto trust-stores: WSS4J 1.6 separates the concept of keystore and truststores. See here and here for more information.
  • WS-SecurityPolicy support for SAML tokens.
  • Initial Apache Aries Blueprint support. This is a work in progress, but many of the Spring namespace handlers that are used with Spring to start/create/configure clients and services now have Blueprint versions as well. See http://cxf.apache.org/schemas/blueprint/ for some of the schemas that have been ported to Blueprint.

Removed modules

The osgi http transport has been removed (cxf-rt-transports-http-osgi) the cxf-rt-transport-http now also supports the osgi case. As the OSGi bundles are separate anyway there are no required changes in the container.

API Changes

  • GZIP related interceptors/features have been moved out of the http module so they are usable with other transports such as JMS. As such, their package has changed from org.apache.cxf.transport.http.gzip to org.apache.cxf.transport.common.gzip
  • XmlSchema has been updated from 1.4.x to 2.0. As such, any use of XmlSchema classes may have changed. In particular, XmlSchema 2.0 uses Java 5 collections which changes how it's used. Also, many static utility methods that existed in org.apache.cxf.common.xmlschema.XmlSchemaUtils have now been merged directly into the XmlSchema API's and are no longer needed or available.
  • WSS4J has been updated from 1.5.x to 1.6. WSS4J 1.6 has dropped the requirement of JDK 1.4, and as such has been upgraded to use Java 5 collections, etc. Some API changes to be aware of include:
    • The SAMLTokenProcessor no longer saves all tokens as an "WSConstants.ST_UNSIGNED" action. It saves tokens that do not have an enveloped signature as this action, and token which do have an enveloped signature are saved as a "WSConstants.ST_SIGNED" action. The object that is saved has changed from an Opensaml1 specific Assertion object, to an AssertionWrapper instance, which is a WSS4J specific object which encapsulates an Assertion, as well as some information corresponding to signature verification, etc.
    • Some changes have been made to the WSPasswordCallback identifiers that are used in a CallbackHandler implementation. See here for more information.
  • Neethi has been upgraded from 2.0.x to 3.0. Due to deficiencies and restrictions in the Neethi 2.0.x API's, CXF has maintained a semi-fork of various parts of Neethi in the org.apache.cxf.ws.policy packages. With CXF 2.4.x and Neethi 3.0, the deficiencies in Neethi have been addressed and the forked changes have been pushed down into Neethi and CXF can better leverage enhancements and new functionality in Neethi directly without duplicating functionality. If you write custom policies for CXF, some changes will be required. These include:
    • The CXF AssertionBuilder interface has been removed. We now use the Neethi AssertionBuilders and Assertions directly.
    • The "getPolicy()" method of PolicyAssertion has been removed. Policies that can contain nested policies should implement the Neethi PolicyContainingAssertion interface directly.
    • Neethi has been updated to be able to process WS-Policy 1.5 policies. Thus, the Assertion interface now has a isIgnorable() method that must be implemented. An implementation of returning false should be adequate and compatible with previous behavior.
    • With the removal of the CXF AssertionBuilder and the implementation if the intersection algorithm in Neethi, the "buildCompatible" method that was on the CXF AssertionBuilder is no longer needed. If a policy needs a custom intersect algorithm, they can now implement the Neethi IntersectableAssertion interface.
    • All locations in CXF that expected the CXF specific PolicyAssertion now expect a normal Neethi Assertion. If the Assertion needs specific logic to determine if it's been asserted, it can implement the CXF PolicyAssertion interface, otherwise the default logic will be used.
    • Since Neethi has been updated to use Java 5 generics, you may need to update and casts and warnings that may occur when calling the new methods that are now typed.
  • JAX-RS Search extensions: org.apache.cxf.jaxrs.ext.search.SearchContext has a new getSearchExpression method returning the raw search query; org.apache.cxf.jaxrs.ext.search.SearchCondition has its toSQL method deprecated and a new accept method added. Please see this page for more information.
  • JAX-RS WADL generation: org.apache.cxf.jaxrs.ext.Description and org.apache.cxf.jaxrs.ext.xml.XMLName have been moved to org.apache.cxf.jaxrs.model.wadl package given that their purpose is to improve the WADL generation. Also, org.apache.cxf.jaxrs.model.wadl.WadlElement has been renamed to 'ElementClass'.

Runtime Changes

  • The ExtensionManagerBus (mostly used when Spring is not available) has been updated to completely support all the features including the WS-SecurityPolicy, WS-RM, etc... features. Previous WSDL documents that contained policy fragments may now behave differently as the policies will be enforced.
  • The default CA certs that ship with the JDK are now not loaded by default by the WS-Security Crypto implementation, which is used for encryption/decryption and signature creation/verification.
  • WSS4J 1.5.x ignored (enveloped) signatures on SAML (1.1) assertions - this is no longer the case, so deployments which do not set the correct keystore/truststore config for dealing with signature verification will fail.
  • The way that UsernameTokens are processed by WSS4J has been changed. See here for more information. The callbackhandler identifier for plaintext passwords is now WSPasswordCallback.USERNAME_TOKEN, the same as for the digest case. The CallbackHandler implementation only sets the password on the callback, and never does any validation of the password.

Property Changes

  • The "ws-security.ut.no-callbacks" property has been renamed to "ws-security.validate.token" and thus in order to configure the CXF WS-Security interceptors to postpone the validation of the current (UT) token one needs to set a "ws-security.validate.token" to false.
    Please see this section for more information.
  • WSS4J 1.6 has added support for separating keystore and truststores. See here and here for more information. The changes are 100% backwards compatible (aside from not loading the default CA certs).
  • The way of creating SAML assertions via a properties file has completely changed. See here and here for more information.