This page describes how to configure transports in the ESB. It contains the following sections:
Configuring Transports Globally
Using the axis2.xml file
WSO2 Carbon and all Carbon-based products ship with a configuration file named
axis2.xml, located in
<PRODUCT_HOME>/repository/conf/axis2 directory. This is similar to the
axis2.xml file that ships with Apache Axis2 and Apache Synapse and contains the global configuration for WSO2 Carbon and the Carbon-based products. The
axis2.xml configuration generally includes configuration details for modules, phases, handlers, global configuration parameters, and transports. The elements <
transportReceiver> and <
transportSender> are used to configure transport receivers and senders respectively. Some transports are already configured and enabled by default, including the HTTP and HTTPS transports.
The HTTP and HTTPS transports are required for the ESB management console and other administrative functions. Do not disable these transports.
WSO2 products do not use the HTTP/S servlet transport configurations that are in
axis2.xml file. Instead, they use Tomcat-level servlet transport configurations in
However, products like WSO2 ESB use the HTTP Pass Through transport in axis2.xml.
Given below is an example of the JMS transport receiver configuration in the axis2.xml file.
transportReceiver> has the following attributes and elements:
- name - A mandatory attribute which indicates a unique name for the transport receiver.
- class - A mandatory attribute which indicates the transport receiver implementation class.
- parameters - Configuration parameters for the transport receiver, such as the port in the example above. Parameters should be included as child elements of the <
transportSender> elements can be used to configure and enable transport senders in WSO2 Carbon. Following is the Pass-through transport sender configuration that comes with WSO2 Carbon by default:
Simply having <
transportReceiver> and <
transportSender> elements in the
axis2.xml file causes those transports to be loaded and activated during server startup. Therefore, any dependency JARs required by those transport implementations must be included in the server classpath (such as the
<ESB_HOME>/repository/components/dropins directory) to prevent the server from running into exceptions at startup. Additionally, an inaccurate transport configuration (such as a wrong parameter value) might cause the transport not to be enabled properly.
axis2.xml file will be loaded into memory at server startup only. Therefore, any changes made to the file while the server is running have no effect until you restart the server.
Configuring servlet transports in standalone mode using the catalina-server.xml file
In addition to configuring transports in
axis2.xml, you can globally configure transport receivers using the
<PRODUCT_HOME>/repository/conf/tomcat/catalina-server.xml file when the server is running in standalone mode (that is, the server is not running in a servlet container). By default, you will find the HTTP and HTTPS servlet transports configured in this file. The XML syntax to configure transports in the
catalina-server.xml file is similar to the syntax used in the
axis2.xml file, except the <
transport> element takes the place of the <
transportReceiver> element. The default HTTP receiver configuration specified in the
catalina-server.xml file is as follows:
Transport receivers configured in
catalina-server.xml will be loaded through a special Transport Manager implementation. Therefore, the classes specified in the <
transport> element must implement the interface
org.wso2.carbon.server.transports.Transport. Currently, only the default servlet transports can be configured from the
Configuring transports at the service level
WSO2 Carbon and Carbon based products allow the user to configure transports at the service level. Transports configured at the service level affect individual services and not all the services deployed in the ESB. Some transport implementations such as JMS and FIX mandate configuring certain transport parameters at the service level.
To configure a transport at the service level, you edit the service's XML file or specify the service-level transport parameters in the proxy service configuration in the management console. For more information, see Working with Web Services.