Setting Up and Reusing a Customized CXF Component

To set up and reuse customized CXF behavior, you must create a global element and reference it within any CXF component in your Mule flow. The following configuration information applies to all types of SOAP API operations: service, client, and proxy.

Studio

On the Global Elements tab of the canvas, select CXF Configuration and click Create.

The Choose Global Type dialog appears.
Select Component configurations > CXF Configuration.
Click OK.

The CXF Configuration dialog appears.
Configure the global CXF configuration attributes according to the following table:
- In Name, enter a unique name for the global element (optional).
- In Configuration Location, if you have created an .xml file that defines behavior of the CXF elements, enter the path and file name to the file in this format: filepath/filename.xml
- Check the Enable Mule SOAP Headers checkbox to ensure that Mule can add a header to a SOAP message when required by the message processing.
- In Initialize Static Bus Instance, check this option to ensure that the CXF SOAP API uses Mule transports instead of CXF transports. The default is checked.
Click OK.

Standalone XML

Above all flows in your Mule project, add a global <cxf:configuration> element. Refer to code sample below.

Configure the global CXF configuration attributes according to the table below.

Attribute Value Description

Attribute	Value	Description
name	unique name	Enter a unique name for the global element, if you want (not required for Mule Runtime).
enableMuleSoapHeaders	true false Note: This field is currently not implemented and has no effect.	If set to true`,` this attribute ensures that Mule can add a header to a SOAP message when required as part of the message’s processing. For example, if your SOAP messages will be processed by a third-party schema which prohibits deviations from very specific message properties and will not process messages with Mule headers, set this attribute to false.
initializeStaticBusInstance	true false	If set to true, (i.e. checked) this attribute ensures that the CXF SOAP API uses Mule transports instead of CXF transports.
configurationLocation	filepath/filename.xml	If you have created an `.xml` file that supplies the specifics of how you want your CXF elements to behave, enter the file path of your CXF configuration file.

name

unique name

Enter a unique name for the global element, if you want (not required for Mule Runtime).

enableMuleSoapHeaders

true
false Note: This field is currently not implemented and has no effect.

If set to true`,` this attribute ensures that Mule can add a header to a SOAP message when required as part of the message’s processing.
For example, if your SOAP messages will be processed by a third-party schema which prohibits deviations from very specific message properties and will not process messages with Mule headers, set this attribute to false.

initializeStaticBusInstance

true
false

If set to true, (i.e. checked) this attribute ensures that the CXF SOAP API uses Mule transports instead of CXF transports.

configurationLocation

filepath/filename.xml

If you have created an .xml file that supplies the specifics of how you want your CXF elements to behave, enter the file path of your CXF configuration file.

To the CXF element within your flow, add a configuration-ref attribute to reference the global CXF configuration element. Refer to code sample below.

<mule xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/cxf http://www.mulesoft.org/schema/mule/cxf/current/mule-cxf.xsd">

    <cxf:configuration name="CXF_Configuration" enableMuleSoapHeaders="true" initializeStaticBusInstance="true" doc:name="CXF Configuration" configurationLocation="src/test/resources/filename.xml"/>

    <http:listener-config name="listener-config" host="localhost" port="8081"/>
    <http:request-config name="request-config" host="localhost"
port="8081"/>
    <flow name="example_flow1" doc:name="example_flow1">
        <http:listener config-ref="listener-config" path="/" doc:name="HTTP Connector"/>
        <cxf:jaxws-client doc:name="SOAP" configuration-ref="CXF_Configuration"/>
        <http:request config-ref="request-config" path="/" method="POST" doc:name="HTTP Connector"/>
    </flow>

Adding Custom Interceptors

CXF uses chains of interceptors, the most basic processing unit, to process messages. As a message moves through an interceptor chain, each interceptor performs an action upon the message, such as reading it, transforming it, or validating it.

If you need to add an extra action to the messages processed by your CXF SOAP API, such as adding a header to a message, use the CXF component to add extra interceptors to the interceptor chain.

Studio

To add a custom interceptor:

Open the properties editor, and on the Interceptors tab, click the drop-down.

The Interceptor Provider options appear:
Select one of the options, for example Add in interceptor.

The selected interceptor option appears in Settings.
Double-click the interceptor option to open the interceptor provider panel.

The in interceptor dialog appears.
From the drop-down in Beans, select a bean.

Alternatively, click new to define a new bean by importing a Java class that defines interceptor behavior.
Click add to list to insert the selected bean into the interceptor chain.
Click Finish, then OK to save your interceptor configuration.

Standalone XML

Above all flows in your Mule project, create a global spring:bean element to import the Java class you have built to specify the interceptor’s behavior. Refer to code sample below.
To the CXF element in your flow, add a child element according to the type of action you want the interceptor to perform:
- cxf:inInterceptor
- cxf:inFaultInterceptor
- cxf:outInterceptor
- cxf:outFaultInterceptor
As a child element of the CXF interceptor element, add a reference to the spring bean, spring:ref bean, you created which imports the Java class.
Add as many as four interceptor child elements to your CXF service or client component.

<spring:beans>
    <spring:bean id="Bean" name="Bean" class="org.mule.example.myClass"/>
</spring:beans>

<http:listener-config name="listener-config" host="localhost" port="8081"/>
<http:request-config name="request-config" host="localhost"
port="8081"/>
<flow name="example_flow1" doc:name="example_flow1">
    <http:listener config-ref="listener-config" path="/" doc:name="HTTP Connector"/>
    <cxf:proxy-service doc:name="SOAP" port="8080"  serviceClass="org.mule.example.bookstore.OrderService"  payload="body" bindingId=" " namespace=" " service="" validationEnabled="true">
       <cxf:inInterceptors>
           <spring:ref bean="Bean"/>
       </cxf:inInterceptors>
    </cxf:proxy-service>
    <http:request config-ref="request-config" path="/" method="GET" doc:name="HTTP Connector"/>
</flow>

Configuring Advanced Elements

You can adjust several advanced CXF SOAP API configurations according to your requirements.

Studio

The Databinding Management configuration options are available for the following operations:

Simple service
JAX-WS Service

extra cxf component configurations 7d94a

The Schema Locations configuration is available only for the Proxy service operation.

The following table describes the advanced configuration elements:

Configuration

Activity

WSDL Location

In the WSDL Location field, enter the URL (relative or absolute) of the WSDL file that describes the functionality of the SOAP API.

MTOM Enabled

Check MTOM Enabled (Message Transmission Optimization Mechanism) to process the binary data sent as part of a SOAP message.

Enable Mule Soap headers

Check the Enable Mule Soap Headers checkbox (the default) to ensure that Mule can add a header to a SOAP message when required as part of the message processing. Uncheck this checkbox to prevent adding headers to SOAP messages. For example, if the SOAP message is processed by a third-party schema, which prohibits deviations from specific message properties, such as added Mule headers, uncheck Enable Mule Soap Headers.

Soap 1.1
*Soap 1.2 *

Select the version of SOAP you want your service to use: SOAP 1.1 or SOAP 1.2. By default, Mule sets the version to SOAP 1.1.

Databinding

With regard to CXF, data binding maps data from XML documents to Java objects. From the drop-down, select a data binding type: aegis-databinding, jaxb-databinding, custom-databinding, or jibx-databinding

Schema Locations

Click add in Schema Locations to specify a schemaLocations attribute that identifies a namespace name and description.

Standalone XML

Within the context of the CXF framework, data binding refers to the mapping of data from XML documents to Java objects. You can specify the databinding of your client or service, if you wish. (Not configurable on proxy service or proxy client.) The following are the different types of databinding available:
- aegis-databinding
- jaxb-databinding
- custom-databinding
- jibx-databinding
To the CXF element in your flow, add a child element according to the type of databinding you want your service or client to use:
- cxf:aegis-databinding
- cxf:jaxb-databinding
- cxf:custom-databinding
- cxf:jibx-databinding
As a child element of the CXF databinding element, add one or more spring:property elements with either a name and value, or name and reference, to define any databinding properties. Refer to the code sample below.
Define a cxf: schemalocations attribute, if you wish, to identify a namespace to which your service should refer. (Not configurable on JAX-WS client, simple client, or proxy client.) Reference schemaLocation for additional details. To the CXF element in your flow (below any interceptor elements, if you have added any), add a ` cxf:schemaLocations ` child element.
Within the cxf:schemaLocations element, add a cxf:schemaLocation child element, to specify the URL of the schema to which your service should refer. Refer to code sample below.
As per your specific needs, configure any of the following CXF service or client attributes according to the table below. Refer to the code sample below.

Configuration

Activity

validationEnabled

When set to true, validationEnabled ensures that Mule can add a header to a SOAP message when required as part of the message’s processing. Set to false if you do not want Mule to add headers to SOAP messages. For example, if your SOAP messages will be processed by a third-party schema which prohibits deviations from very specific message properties (such as added Mule headers), set validationEnabled to false.

mtomEnabled

Set mtomEnabled to true if you want Mule to process the binary data sent as part of a SOAP message. (Message Transmission Optimization Mechanism)

wsdlLocation

Enter the URL (relative or absolute) of the WSDL file which describes the functionality of the SOAP API.

soapVersion

Identify the version of SOAP you want your service to use: SOAP 1.1 or SOAP 1.2. By default, Mule uses SOAP 1.1.