THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 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...
- 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.
Dependency Changes
- 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
...