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 Name | Description |
---|---|
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 Name | Description | Default 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 Name | Attribute | Description |
---|---|---|
<phase> | name | You add phases using the In the Out phase orders, phases before the The name attribute specifies the phase name. You can add the |
<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). |