Versions Compared

Old Version 10

changes.mady.by.user Daniel Kulp

Saved on

compared with

New Version 11

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.

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.