7.5. API Changes
Removed classes
The following classes and interfaces have been removed in Apache CXF 3.0.x:
org.apache.cxf.bus.CXFBusImpl org.apache.cxf.databinding.BaseDataReader org.apache.cxf.databinding.BaseDataWriter org.apache.cxf.transports.http.QueryHandler org.apache.cxf.transports.http.StemMatchingQueryHandler org.apache.cxf.transports.http.internal.QueryHandlerRegistryImpl org.apache.cxf.helpers.XMLUtils org.apache.cxf.ws.addressing.impl.AddressingPropertiesImpl org.apache.cxf.common.xmlschema.XmlSchemaConstants org.apache.cxf.common.util.SOAPConstants org.apache.cxf.frontend.MethodDispatcher org.apache.cxf.jaxb.JAXBToStringBuilder org.apache.cxf.jaxb.JAXBToStringStyle org.apache.cxf.interceptor.URIMappingInterceptor org.apache.cxf.jaxrs.ext.form.Form org.apache.cxf.jaxrs.ext.ParameterHandler org.apache.cxf.jaxrs.ext.RequestHandler org.apache.cxf.jaxrs.ext.ResponseHandler
org.apache.cxf.Bus.run() method
The
org.apache.cxf.Bus.run()
method has been removed, because it is no longer used.
org.apache.cxf.transport.Destination.getBackChannel method
The two unused parameters of the
org.apache.cxf.transport.Destination.getBackChannel
method (normally passed as null) have been removed. That is, in previous versions, the getBackChannel
method had the following signature:
Conduit getBackChannel(Message inMessage, Message unused1, EndpointReferenceType unused2)
In version 3.0.x, the
getBackChannel
method now has the following signature:
Conduit getBackChannel(Message inMessage)
Spring XML files
All files of the form
/META-INF/cxf/cxf-extension-ExtensionName.xml
have been removed in version 3.0.x. At one time, it was necessary to xi:include
such files into your Spring XML file, in order to use a particular extension feature. These files have not been needed and have been deprecated for a long time.
org.apache.cxf.transport.ConduitInitiator and DestinationFactory interfaces
Some of the methods of the
org.apache.cxf.transport.ConduitInitiator
and DestinationFactory
interfaces now take an additional parameter of type, org.apache.cxf.Bus
. In particular, ConduitInitiator
defines the following method signatures in version 3.0.x:
Conduit getConduit(EndpointInfo targetInfo, Bus bus) throws IOException; Conduit getConduit(EndpointInfo localInfo, EndpointReferenceType target, Bus bus) throws IOException; Set<String> getUriPrefixes(); List<String> getTransportIds();
And
DestinationFactory
defines the following method signatures in version 3.0.x:
Destination getDestination(EndpointInfo ei, Bus bus) throws IOException; Set<String> getUriPrefixes(); List<String> getTransportIds();
bus-extensions.xml file
When implementing an extension to the CXF Bus, the
bus-extensions.xml
file is no longer supported. Instead, use the approach of defining a bus-extensions.txt
file. In the JAR file that implements your Bus extension, create the file, META-INF/cxf/bus-extensions.txt
, and in this file list the classname of the class that implements the extension. The CXF Bus will automatically instantiate your extension class when it is needed.
Refactored XML parsing utilities
All code for StAX-based XML parsing and writing has been moved into the
org.apache.cxf.staxutils.StaxUtils
class and DOM-based utility code to the org.apache.cxf.helpers.DOMUtils
class. The org.apache.cxf.helpers.XMLUtils
class has been eliminated.
AddressingProperties interface is now a class
The
org.apache.cxf.ws.addressing.AddressingProperties
interface has been turned into a concrete class, which can be created directly using new
. The AddressingPropertiesImpl
class has been removed.
Policy classes in the org.apache.cxf.ws.policy package
Many of the classes in the
org.apache.cxf.ws.policy
package, such as AlternativeSelector
and PolicyEngine
, have modified method signatures, which now pass the current Message
as an additional parameter (where appropriate). This makes it possible to use the message context to select a policy alternative. However, you must keep in mind that the selected alternative is probably cached and therefore, if the contextual information changes, the alternative might not be recalculated.
New supportNotAvailableErrorsOnly property on FailoverTargetSelector
By default, the
org.apache.cxf.clustering.FailoverTargetSelector
class triggers failover only for HTTP 404 and HTTP 503 status errors. If you would prefer to fail over for all HTTP errors, set the new supportNotAvailableErrorsOnly
property to false
.
ServletController not overriding endpoint addresses by default
The
org.apache.cxf.transport.servlet.ServletController
class does not override endpoint addresses by default, because this would have unwanted side-effects, if an endpoint is accessed through multiple paths. If you would like to revert to the old behaviour, set disable-address-updates
parameter to false
on the CXFServlet
class.
SchemaValidation annotation
The
enabled
property (previously deprecated) has been removed from the org.apache.cxf.annotations.@SchemaValidation
annotation. Use the @SchemaValidation.type
property to control the validation instead.
FactoryType annotation
In the
org.apache.cxf.annotations.@FactoryType
annotation, the FactoryType.Type
enumeration no longer includes the value, Spring
. In version 3.0.x, to select Spring, set factoryClass=SpringBeanFactory.class
.
org.apache.cxf.jaxrs.ext.form.Form class
The
org.apache.cxf.jaxrs.ext.form.Form
has been removed in version 3.0.x. Use the JAX-RS 2.0 org.apache.cxf.jaxrs.ext.form.Form
class instead. For example, you would replace the following (obsolete) JAX-RS 1.0 code:
// JAX-RS 1.0 (obsolete) import org.apache.cxf.jaxrs.ext.form.Form; ... Form form = new Form().set("a", "b");
With the following JAX-RS 2.0 compliant code:
// JAX-RS 2.0 import javax.ws.rs.core.Form; ... Form form = new Form().param("a", "b");
org.apache.cxf.jaxrs.ext.ParameterHandler<T> interface
The
org.apache.cxf.jaxrs.ext.ParameterHandler<T>
interface has been removed in Apache CXF 3.0.x. Use the javax.ws.rs.ext.ParamConverterProvider
class instead, which can be used both on the client side and on the server side.
org.apache.cxf.jaxrs.ext.RequestHandler and ResponseHandler interfaces
The
org.apache.cxf.jaxrs.ext.RequestHandler
and ResponseHandler
filters have been removed in Apache CXF 3.0.x. Use the javax.ws.rs.container.ContainerRequestFilter
and ContainerResponseFilter
interfaces instead.
For example, to define your own
CustomerRequestFilter
and CustomResponseFilter
filter classes, you could write code like the following:
// Java import javax.ws.rs.container.ContainerRequestFilter; import javax.ws.rs.container.ContainerResponseFilter; ... public class CustomRequestFilter implements ContainerRequestFilter { public void filter(ContainerRequestContext context) { ... } } public class CustomResponseFilter implements ContainerResponseFilter { public void filter(ContainerRequestContext inContext, ContainerResponseContext outContext) { ... } }
JaxWsClientProxy.getClient(proxy) and ClientProxy.getClient(proxy)
It is no longer necessary to call the
getClient(proxy)
method on the org.apache.cxf.jaxws.JaxWsClientProxy
class (for the JAX-WS front-end) or the org.apache.cxf.frontend.ClientProxy
class (for the simple front-end) in order to convert a proxy object to a org.apache.cxf.endpoint.Client
object. Because the proxies now implement the Client
interface directly, you can simply cast a proxy object directly to a Client
object.
javax.annotation.Resource annotation
The
javax.annotation.Resource
annotation can no longer be used to annotate JAX-RS context properties. For the JAX-RS binding, only the javax.ws.rs.core.Context
annotation is supported from now on.