Contact Us 1-800-596-4880

Migrating Transports

This version of Mule reached its End of Life on May 2, 2023, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Mule 3 transports have been replaced by connectors, which follow an operation model in Mule 4. Most Mule transports are replaceable by a corresponding connector in Mule 4.

Some migration issues are common to all transports. For transport-specific migration documentation, refer to Migrating Connectors and Modules to Mule 4 and its child pages, instead.

Endpoint Addresses

In Mule 3, an endpoint could be configured with either transport-specific attributes (for example, an HTTP endpoint could use host, port, and path) or with the generic address attribute.

Whenever the generic address attribute was used, it was possible to reference a property, for example:

<http:inbound-endpoint address="${External.URL}"/>

The properties configuration for External.URL looks something like this:

External.URL=http://0.0.0.0:8080/rootPath

In Mule 4, the connectors define the connection attributes separately, so any full address property has to be split into its components.

<http:listener-config name="listenerConfig">
    <http:listener-connection host="${External.URL.host}" port="${External.URL.port}"/>
</http:listener-config>

<flow>
    <http:listener config-ref="listenerConfig" path="${External.URL.path}"/>

    ...
</flow>

The configuration for the properties becomes:

External.URL.host=0.0.0.0
External.URL.port=8080
External.URL.path=/rootPath

Connector-specific documentation (such as for the HTTP or Email connector) provides detail on the exact properties that the connector requires.

Service Overrides

In Mule 4, service override customizations through custom Java code are not supported in Mule 4.

In Mule 3, it is possible to customize the behavior of a transport through a connector’s service-overrides element. This element provides a way to reference Java classes with custom code that provides the new functionality.

Mule 3 Example: Connector with service-overrides
<imap:connector name="imapConnector" moveToFolder="processed" deleteReadMessages="false" checkFrequency="200">
    <service-overrides messageReceiver="org.mule.transport.email.functional.RetrieveMessageReceiverPollCounter"/>
</imap:connector>

The way to migrate such customizations to Mule 4 depends on what the custom code does, so you might:

  • Provide the functionality through another Mule feature or component, such as a DataWeave transformation, a Java Module, or a Scripting Module).

  • Use the Mule SDK to create a connector that provides your customized transport functionality. As a starting point, you can use open-source connectors as dependencies (for example, https://github.com/mulesoft/mule-http-connector).

  • Similar to the previous approach, you can fork an open-source connector repository and add your custom code to the fork. MuleSoft welcome Pull Requests for your changes.

  • Provide a feature request to MuleSoft. You can request that MuleSoft add the functionality that your custom code provided through service-overrides. Visit MuleSoft Support Ideas to submit such requests.