cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache CXF Documentation > 2.4 Migration Guide
Date Thu, 07 Apr 2011 14:52:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/2042/9/1/_/styles/combined.css?spaceKey=CXF20DOC&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="">2.4
Migration Guide</a></h2>
    <h4>Page <b>edited</b> by             <a href="">Colm
O hEigeartaigh</a>
                         <h4>Changes (1)</h4>
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" > ** Performance work: A general code-rewrite
has been done with a focus on improving performance.  <br> ** Support for Crypto trust-stores:
WSS4J 1.6 separates the concept of keystore and truststores. See [here|]
and [here|]
for more information. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">*
WS-SecurityPolicy support for SAML tokens. <br></td></tr>
            <tr><td class="diff-unchanged" > <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h3><a name="2.4MigrationGuide-NewFeatures"></a>New Features</h3>

	<li>LogBrowser console</li>
	<li>Transformation feature provides for a fast and effective way to transform inbound
and/or outbound XML messages, please see the <a href="/confluence/display/CXF20DOC/TransformationFeature"
title="TransformationFeature">TransformationFeature</a> page for more information.</li>
	<li>JIBX databinding</li>
	<li>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.</li>
	<li>WSS4J has been updated from 1.5.x to 1.6. See <a href=""
class="external-link" rel="nofollow">here</a> (not yet live) for the list of new
features and upgrade notes for Apache WSS4J 1.6. Also see <a href=""
class="external-link" rel="nofollow">Colm's blog</a> for an ongoing list of things
that are happening in WSS4J 1.6. Some notable new features for CXF users include:
		<li>SAML2 support: WSS4J 1.6 includes full support for creating, manipulating and
parsing SAML2 assertions, via the Opensaml2 library. See <a href=""
class="external-link" rel="nofollow">here</a> for more information.</li>
		<li>Performance work: A general code-rewrite has been done with a focus on improving
		<li>Support for Crypto trust-stores: WSS4J 1.6 separates the concept of keystore and
truststores. See <a href=""
class="external-link" rel="nofollow">here</a> and <a href=""
class="external-link" rel="nofollow">here</a> for more information.</li>
	<li>WS-SecurityPolicy support for SAML tokens.</li>

<h3><a name="2.4MigrationGuide-APIChanges"></a>API Changes</h3>

	<li>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</li>

	<li>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.</li>

	<li>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:
		<li>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.</li>
		<li>Some changes have been made to the WSPasswordCallback identifiers that are used
in a CallbackHandler implementation. See <a href=""
class="external-link" rel="nofollow">here</a> for more information.</li>

	<li>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 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:
		<li>The CXF AssertionBuilder interface has been removed.   We now use the Neethi AssertionBuilders
and Assertions directly.</li>
		<li>The "getPolicy()" method of PolicyAssertion has been removed.  Policies that can
contain nested policies should implement the Neethi PolicyContainingAssertion interface directly.</li>
		<li>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.</li>
		<li>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.</li>
		<li>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.</li>
		<li>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.</li>

	<li>JAX-RS Search extensions: has a new
getSearchExpression method returning the raw search query;
has its toSQL method deprecated and a new accept method added. Please see <a href=""
class="external-link" rel="nofollow">this page</a> for more information.</li>

	<li>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'.</li>

<h3><a name="2.4MigrationGuide-RuntimeChanges"></a>Runtime Changes</h3>

	<li>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.</li>

	<li>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.</li>

	<li>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.</li>

	<li>The way that UsernameTokens are processed by WSS4J has been changed. See <a
href="" class="external-link"
rel="nofollow">here</a> 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.</li>

<h3><a name="2.4MigrationGuide-PropertyChanges"></a>Property Changes</h3>

	<li>The "" 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.<br/>
Please see this <a href="/confluence/display/CXF20DOC/Security#Security-WSSecurityUsernameTokenandCustomAuthentication">section</a>
for more information.</li>

	<li>WSS4J 1.6 has added support for separating keystore and truststores. See <a
href="" class="external-link"
rel="nofollow">here</a> and <a href=""
class="external-link" rel="nofollow">here</a> for more information. The changes are
100% backwards compatible (aside from not loading the default CA certs).</li>

	<li>The way of creating SAML assertions via a properties file has completely changed.
See <a href=""
class="external-link" rel="nofollow">here</a> and <a href=""
class="external-link" rel="nofollow">here</a> for more information.</li>

        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href=""
class="grey">Change Notification Preferences</a>
        <a href="">View
        <a href="">View
        <a href=";showCommentArea=true#addcomment">Add

View raw message