Versions Compared

Old Version 12

changes.mady.by.user Daniel Kulp

Saved on

compared with

New Version 13

changes.mady.by.user Daniel Kulp

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The org.apache.cxf.tools.* classes that were in cxf-api have been moved into cxf-tools-common or cxf-tools-validator.
  • The org.apache.cxf.ws.policy classes that were in cxf-api have been moved into cxf-rt-ws-policy.
  • cxf-common-utilities is no longer available. All the classes in there were moved into cxf-api to represent a complete "api".
  • Various classes in cxf-rt-core and cxf-rt-ws-addr have been moved up to cxf-api to resolve split-package issues. Dependencies on cxf-rt-core would have transitively brought in cxf-api anyway, so there should be little impact.
  • Spring is now an optional component of the http-jetty transports module and other modules. Applications that may have pulled in Spring transitively via CXF will be required to declare required spring dependencies in their own poms directly.
  • Most of the optional JAX-RS Providers have been moved out of the cxf-rt-frontend-jaxrs module and into a cxf-rt-rs-extension-providers module with the various dependencies marked optional/provided. Applications that use these optional providers will need to add the required dependencies. Also, the package names of many of those providers has changed to resolve split-package issues. Example: org.apache.cxf.jaxrs.provider.JSONProvider -> org.apache.cxf.jaxrs.provider.json.JSONProvider

Runtime Changes

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