Aaron H. Kim Fearless Integration Maniac

How to use Echo component since Mule run-time 3.8


I have followed a very simple Echo example to learn how to use Echo component in mule. The first thing I noticed was that the example was written for Mule 3.4. This example would work up to 3.7 but not after 3.8. And sadly there isn’t up to date example for 3.8. So, let me brief things that I have found here. As always, please comment if I got something wrong or have something to add.

Source code

You can find source code for this practice here.

What’s not working

Unlike the guide, when you give a request like following,


it won’t response


instead, it will complain

No listener for endpoint: /mule


The reason why it does this is because the guide uses the old HTTP endpoint-based Connector instead of the New HTTP Connector which was introduced in Mule 3.7 Runtime. 3.7 Runtime still supports HTTP endpoint-based connector but deprecated since.

Key Differences in between old and new connector

So, knowing and understanding the key differences between old and new connector to be able to work with Samples written for old runtime. Sadly, all the currently available Mule books and Samples from Mulesoft are still targeted only for older version(Mulesoft training of course is a different story).

  • Key Differences to note
  1. On the old HTTP Connector, both for inbound and outbound endpoints, it was possible to set up the exchange-pattern so that messages only went in one direction, so inbound endpoints would send no request back to the requestor, and outbound endpoints would not listen for a response to their requests. The new HTTP Connector always has a two way communication.

  2. In the old http:inbound-endpoint the value of path cannot start with a slash. In the new http:listener the value of path can.

  3. The new HTTP connector also differs from the old connector in how it maps elements of the HTTP request to elements in the Mule Message, overall it behaves in a more consistent and predictable way. It is important to mark these differences, as referencing these incoming elements from other blocks in your flow now requires employing different MEL expressions when using the new HTTP connector.
  4. while the old connector listens by default to all subpaths below the one you define – the new HTTP Connector only listens to the specific path you define. If you wish the new connector to accept subpaths, you can end the path with a wildcard (*)


Difference 4 was why you could send a GET request like localhost:8081/mule and expects to receive a response of /mule. This will now results in No listener for endpoint: /mule in new HTTP Connector.

As suggested, you could make it accepts subpaths - just like before with a wildcard(*). But, Echo component this time won’t behave as before either because of the difference 3.

The purpose of Echo component is

Use Echo to echo or display the message payload. Note that the component transforms the payload into a String.

Although, Echo component is marked deprecated by Mule documentation, it still does the job of printing message payload.

However, not the same way as it did in guide. After enabling subpaths by entering path with wildcard(*), you won’t get a complaint but won’t get a response of echo either.

If you still want the echo to work, you will need to give a POST request with entering message in request body as follows

When you see how request maps to mule message in the picture for Difference 3, only body part will become a payload. This makes sense and matches the purpose of Echo component.


Similar Posts