This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Configuring axis2_blocking_client.xml

This file contains parameters which apply to scenarios where blocking transports are used i.e. Message Processors and the Callout Mediator. These parameters are grouped as follows.

Parameters

This section is used to add parameters to be applied to scenarios in which blocking transports are used.

A parameter is a name-value pair. All top-level parameters (those that are direct sub-elements of the root element) will be transformed into properties in the AxisConfiguration and can be accessed in the running system. The name attribute (required) specifies the parameter name. If you set the locked attribute to true (the default value is false), this parameter's value cannot be overridden by services and other configurations.

Message Receivers

This section is used to add message receivers that can be used in scenarios where blocking transports are used. The class attribute specifies the implementation class of the message receiver. The mep attribute specifies the message exchange pattern supported by the message receiver.

The following example shows the format in which a message receiver can be added.

<messageReceivers>
        <messageReceiver mep="http://www.w3.org/ns/wsdl/in-only"
                         class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
</messageReceivers>

Message Formatters

This section is used to define message formatters to be used in scenarios where blocking transports are used. A message formatter is used to build the outgoing stream of a message. The contentType attribute specifies which message types are handled by this formatter, and the class attribute specifies the formatter implementation class. See Working with Message Builders and Formatters for more information.

Message formatters can be added using the format shown in the example below.

<messageFormatters>
        <messageFormatter contentType="application/x-www-form-urlencoded"
                          class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
</messageFormatters>

Message Builders

This section is used to define message builders to be used in scenarios where blocking transports are used. A message builder is used by transport receivers to process the raw data in the payload of a received message and convert it to the SOAP format. The contentType attribute specifies which message types are handled by this builder, and the class attribute specifies the builder implementation class. See Working with Message Builders and Formatters for more information.

Message builders can be added using the format shown in the example below.

<messageBuilders>
        <messageBuilder contentType="application/xml"
                        class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
</messageBuilders>

Transport Ins

Transport receivers can be added in this section using the format shown in the example below.

  <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
        <parameter name="myTopicConnectionFactory">
        	<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
        	<parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
        	<parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
		<parameter name="transport.jms.ConnectionFactoryType" locked="false">topic</parameter>
        </parameter>
  </transportReceiver>

Configurable parameters for each transport receiver are as follows. 

Parameter NameDescription
java.naming.factory.initial
JNDI initial context factory class. The class must implement thejava.naming.spi.InitialContextFactoryinterface.
java.naming.provider.url
The URL of the JNDI provider.
transport.jms.ConnectionFactoryJNDIName
The JNDI name of the connection factory.
transport.jms.ConnectionFactoryType
The type of the connection factory.

Transport Outs

Transport senders can be added in this section using the format shown in the example below.

<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>
        <parameter name="cacheHttpClient">true</parameter>
        <parameter name="defaultMaxConnectionsPerHost">200</parameter>
        <!-- If following is set to 'true', optional action part of the Content-Type will not be added to the SOAP 1.2 messages -->
        <!--  <parameter name="OmitSOAP12Action">true</parameter>  -->
</transportSender>

Configurable parameters for each transport sender are as follows.

Parameter NameDescriptionDefault Value
PROTOCOL
The transport protocol. 
Transfer-Encoding
This parameter enables you to specify whether the data sent should be chunked. It can be used instead of the Content-Length header if you want to upload data without having to know the amount of data to be uploaded in advance. 
cacheHttpClient
This parameter is used to specify whether the HTTP client should save cache entries and the cached responses in the JVM memory or not. 
defaultMaxConnectionsPerHost
The maximum number of connections that will be created per host server by the client. If the backend server is slow, the connections in use at a given time will take a long time to be released and added back to the connection pool. As a result, connections may not be available for some requests and you may get the org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout waiting for connection error. In such situations, it is recommended to increase the value for this parameter.2

Global Modules

This section is used to engage a module. The ref attribute specifies the module name.

<module ref="addressing"/>

Clustering

This section is used to enable clustering. The class attribute specifies the clustering agent class. The enable attribute can be set it to true to enable clustering. It is set to false by default.

Phases

This section is used to specify the order of phases in the execution chains of different types of flow. The type of flow to which the phasing is defined is specified by the attribute and it can be one of the following.

  • InFlow
  • OutFlow
  • InFaultFlow
  • OutFaultFlow

The following configuration is an example of how phases are configured.

<phaseOrder type="InFlow">
        <!--  System pre defined phases       -->
        <phase name="Transport">
            <handler name="RequestURIBasedDispatcher"
                     class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher">
                <order phase="Transport"/>
            </handler>
            <handler name="SOAPActionBasedDispatcher"
                     class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher">
                <order phase="Transport"/>
            </handler>
        </phase>
        <phase name="Addressing">
             <handler name="AddressingBasedDispatcher"
                     class="org.apache.axis2.dispatchers.AddressingBasedDispatcher">
                 <order phase="Addressing"/>
            </handler>
        </phase>
        <phase name="Security"/>
        <phase name="PreDispatch"/>
        <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase">
            <handler name="RequestURIBasedDispatcher"
                     class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher"/>
            <handler name="SOAPActionBasedDispatcher"
                     class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher"/>
            <handler name="RequestURIOperationDispatcher"
                     class="org.apache.axis2.dispatchers.RequestURIOperationDispatcher"/>
            <handler name="SOAPMessageBodyBasedDispatcher"
                     class="org.apache.axis2.dispatchers.SOAPMessageBodyBasedDispatcher"/>
            <handler name="HTTPLocationBasedDispatcher"
                     class="org.apache.axis2.dispatchers.HTTPLocationBasedDispatcher"/>
        </phase>
        <phase name="RMPhase"/>
        <!--  System predefined phases       -->
        <!--   After Postdispatch phase module author or service author can add any phase he want      -->
        <phase name="OperationInPhase"/>
        <phase name="soapmonitorPhase"/>
    </phaseOrder>
    <phaseOrder type="OutFlow">
        <!--      user can add his own phases to this area  -->
        <phase name="soapmonitorPhase"/>
        <phase name="OperationOutPhase"/>
        <!--system predefined phase-->
        <!--these phase will run irrespective of the service-->
        <phase name="RMPhase"/>
        <phase name="PolicyDetermination"/>
        <phase name="MessageOut"/>
        <phase name="Security"/>
    </phaseOrder>
    <phaseOrder type="InFaultFlow">
        <phase name="Addressing">
             <handler name="AddressingBasedDispatcher"
                     class="org.apache.axis2.dispatchers.AddressingBasedDispatcher">
                 <order phase="Addressing"/>
            </handler>
        </phase>
        <phase name="Security"/>
        <phase name="PreDispatch"/>
        <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase">
            <handler name="RequestURIBasedDispatcher"
                     class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher"/>
            <handler name="SOAPActionBasedDispatcher"
                     class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher"/>
            <handler name="RequestURIOperationDispatcher"
                     class="org.apache.axis2.dispatchers.RequestURIOperationDispatcher"/>
            <handler name="SOAPMessageBodyBasedDispatcher"
                     class="org.apache.axis2.dispatchers.SOAPMessageBodyBasedDispatcher"/>
            <handler name="HTTPLocationBasedDispatcher"
                     class="org.apache.axis2.dispatchers.HTTPLocationBasedDispatcher"/>
        </phase>
        <phase name="RMPhase"/>
        <!--      user can add his own phases to this area  -->
        <phase name="OperationInFaultPhase"/>
        <phase name="soapmonitorPhase"/>
    </phaseOrder>
    <phaseOrder type="OutFaultFlow">
        <!--      user can add his own phases to this area  -->
        <phase name="soapmonitorPhase"/>
        <phase name="OperationOutFaultPhase"/>
        <phase name="RMPhase"/>
        <phase name="PolicyDetermination"/>
        <phase name="MessageOut"/>
        <phase name="Security"/>
    </phaseOrder>

The configurable parameters for this section are as follows. 

Parameter NameAttributeDescription
<phase>name

 You add phases using the <phase> sub-element. In the In phase orders, all phases before the Dispatch phase are global phases, and phases after the Dispatch phase are operation phases.

In the Out phase orders, phases before the MessageOut phase are global phases, and phases after the MessageOut phase are operation phases.

The name attribute specifies the phase name. You can add the <handler> sub-element under <phase> to execute a specific handler during a phase.

<handler>name
class 
The handler (message processing functionality) to execute during this phase. Handlers are combined into chains and phases to provide customizable functionality such as security, reliability, etc. Handlers must be multi-thread safe and should keep all their state in Context objects (see the org.apache.axis2.context package).