Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

  • The big OSGi bundle used in the Karaf features.xml has been replaced with the individual modules which are now all individual bundles. The big OSGi bundle is still built, but some features may not be available if that is used instead of the little bundles.
  • New ability to configure HTTP Conduits from the OSGi config:admin service
  • New ability to configure the CXF created HTTP Jetty ports from config:admin service
  • OAuth 2 support (new cxf-rt-rs-security-oauth2 module)
  • The STS now supports the Renewal binding for SAML tokens.
  • The STS also supports bulk issuing/validation/cancelling/renewal of security tokens.
  • The STS supports some advanced features based around Claims, such as Claims Transformation, and pluggable custom Claims Parsing.
  • The WS-Security module now supports replay detection by default of Timestamps and UsernameToken nonces.
  • New ability to register custom JAX-RS Context providers.
  • New @UseAsyncMethod annotation for JAX-WS services.

Removed Modules

  • cxf-common-utilites was merged into cxf-api
  • cxf-rt-binding-http has been removed. It's been "deprecated" for a while and it's functionality has long been replaceable with the JAX-RS frontend.

...

  • All API's that take or return "generic" classes have been update to properly define the generic part. For example, methods like:
    "Class getServiceClass()" have been updated to be "Class<?> getServiceClass()"
  • To resolve some of the "split-package" issues between jars, SOME (very few) classes did have their packages changed.
    • org.apache.cxf.jaxb.JAXBUtils -> org.apache.cxf.common.jaxb.JAXBUtils (and a couple other classes in that jaxb package)
    • Many of the internal "Impl" classes and "Managers" (like BindingFactoryManagerImpl, CXFBusLifeCycleManager, etc...) have moved into org.apache.cxf.bus.managers. Users should always rely on the interfaces they implement anyway.
  • The selectedConduit field of AbstractConduitSelector has been removed as a ConduitSelector may be used to select multiple conduits depending on scenarios and the selectedConduit field may not accurately reflect the conduit that had been selected depending on the state of the threads, clients, etc...
  • The classes in org.apache.cxf.tools.common.extensions.soap have been moved to org.apache.cxf.binding.soap.wsdl.extensions to remove a runtime dependency on the tooling modules.
  • org.apache.cxf.tools.common.DataTypeAdapter has been deprecated and moved to org.apache.cxf.xjc.runtime.DataTypeAdapter in a new runtime jar that is part of the cxf-xjc package. This allows using the runtime without bringing in all the CXF tooling dependencies. The DataTypeAdapter doesn't have any other CXF dependencies and thus is usable outside of CXF as well.
  • The XJC "ToString" plugin also had it's runtime dependencies moved out of org.apache.cxf.tools and into the cxf-xjc-runtime jar. If you use the newer version of the ToString plugin, you will need to add the cxf-xjc-runtime dependency to your application. However, the cxf-xjc-runtime jar does not depend on other CXF jars or classes and can thus be easily used in other applications without as many dependencies pulled in.

...

  • The syntax of WS-SecurityPolicy policies is enforced more strictly. Some policies that worked with CXF < 2.6 will not load in CXF 2.6 as a result.
  • JMS Transport - when using TextMessage, CXF now leaves the contents as a String and uses java.io.Reader and java.io.Writer to boost performance. Previously, CXF would convert the Strings to/from byte[] requiring use of encoders, increasing memory usage, etc... However, some interceptors and functionality in CXF (or user interceptors) may expect or require they InputStream/OutputStreams, not Reader/Writer. In those cases, you may need to change to use a BytesMessage. For example, the FastInfoset feature and GZIP features expect to work on InputStream/OutputStream and thus would now work with TextMessage.

Security Caching Changes

  • EhCache is now used by default to cache SecurityTokens for re-use, and for replay detection. It is possible to plug in other implementations by configuration.
  • The WS-Security module now supports replay detection by default of Timestamps and UsernameToken nonces. The default caching time is 60 minutes.
  • The STS now issues SAML and SecurityContextTokens with a default lifetime of 30 minutes (they are also stored in the cache for this length of time).