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.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.