[CONF] Apache CXF Documentation > 2.4 Migration Guide

[confluence]

2.4 Migration Guide Page edited by Colm O hEigeartaigh Changes (3) ... * 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. * Improved SAML support, including support for SAML2 tokens. ... * WSS4J has been updated from 1.5.x to 1.6. See [Colm's blog|http://coheigea.blogspot.com/] for and ongoing list of things that are happening in WSS4J 1.6. This page will be updated as that solidifies. See [here|http://ws.apache.org/wss4j/wss4j16.html] (not yet live) for the list of new features and upgrade notes for Apache WSS4J 1.6. Also see [Colm's blog|http://coheigea.blogspot.com/] 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|http://coheigea.blogspot.com/2011/02/support-for-saml2-assertions-in-wss4j.html] 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|http://coheigea.blogspot.com/2011/01/wss4j-16-crypto-property-change.html] and [here|http://coheigea.blogspot.com/2011/02/wss4j-16-changes-to-crypto-interface.html] for more information. Some upgrade notes to be aware of include: ** The default CA certs that ship with the JDK are now not loaded by default by the Crypto implementation. ** The way of creating SAML assertions via a properties file has completely changed. ** 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 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. ** The way that UsernameTokens are processed has been changed. See [here|http://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html] for more information. The callbackhandler identifier for plaintext passwords is now WSPasswordCallback.USERNAME_TOKEN, the same as the digest case. The CallbackHandler implementation only sets the password on the callback, and never does any validation of the password. ** Some changes have been made to the WSPasswordCallback identifiers. See [here|http://coheigea.blogspot.com/2011/02/wspasswordcallback-changes-in-wss4j-16.html] 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: ... Full Content 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. Improved SAML support, including support for SAML2 tokens. 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. 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. Some upgrade notes to be aware of include: The default CA certs that ship with the JDK are now not loaded by default by the Crypto implementation. The way of creating SAML assertions via a properties file has completely changed. 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 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. The way that UsernameTokens are processed has been changed. See here for more information. The callbackhandler identifier for plaintext passwords is now WSPasswordCallback.USERNAME_TOKEN, the same as the digest case. The CallbackHandler implementation only sets the password on the callback, and never does any validation of the password. Some changes have been made to the WSPasswordCallback identifiers. 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. CXF 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. 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. 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. Change Notification Preferences View Online | View Changes | Add Comment