Revisiting Dynamic Ports in Mule 3

Daniel Zapata wrote an interesting post about using dynamic ports when testing your Mule 3 application. Since then, subsequent releases of Mule included support for JUnit 4 which meant improved flexibility in terms of dynamic ports.

Before JUnit 4, an annoying problem with dynamic ports was that you were limited to property placeholder names having the following pattern: 'port' + n where n is an integer. For example:

Using JUnit 4, this problem is solved by leveraging the Rule annotation and the DynamicPort class. We'll see how this is done. Let's create a simple Mule config for testing dynamic ports out:

Notice the property placeholder "${foo}" in the port attribute. The next step is to create a test case for the config. The test case must extend org.mule.tck.junit4.FunctionalTestCase for this to work:

The port variable declaration is what we're interested in. @Rule instructs JUnit to execute code in the DynamicPort object before running the test. The code will:

1. Find an unused port,
2. Search the Mule config for a placeholder with the name 'foo', and then
3. Replace the placeholder with the unused port number.

The newly assigned port no. is retrieved using the getNumber() method of the DynamicPort class. The complete example can be found on GitHub.

Conventions, Conventions, Conventions

I've been working with open source projects for a couple of years now and I've come to expect two things from such projects:

• A set of working examples that comes with the distribution, and a

• Quick guide on getting started.

Mule has them. ServiceMix has them. So why not Spring Integration? It's a shame because I heard a lot of good things about the software. I couldn't find a reason why SpringSource didn't post an official guide on getting started quickly in their main page. However, they do have a reason for leaving examples out from the distribution. Although for me, it's not a good enough reason. 

As a frequent user of open source projects, I'm accustomed to certain conventions. For instance, I expect to find a "README.txt" in the distribution's root folder telling me how to launch the program. When you decide to stay away from conventions, new users have to rely on Google to find what they're looking for. This is great for Google but not for your open source project since the user might get fed up searching and just try another project. I spent about 5 minutes searching for a simple Spring Integration example. This could have been because I chose a poor search term or I'm a slow reader, but still, for me it was a waste time. Doing the same thing in Mule or ServiceMix took me a second. Why? Not because I used Mule or ServiceMix before but because I expected there would be example folders in their distributions. Which project do you think the impatient user will have a better experience learning?