Firstly, please take a look at these filthy builds of our Mule Forge plan:

At build 15, An ugly test was not removed mistakenly and it ran for about 4 hours before someone killed it. The dirty thing left was the admin agent port being held up by Bamboo, for whatever reason it is:

Caused by: org.mule.providers.ConnectException: Failed to bind to uri "tcp://localhost:60504"
	at org.mule.providers.tcp.TcpMessageReceiver.doConnect(TcpMessageReceiver.java:77)
	at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:406)
	at org.mule.providers.SingleAttemptConnectionStrategy.doConnect(SingleAttemptConnectionStrategy.java:26)
	... 33 more
Caused by: java.net.BindException: Address already in use

For all of our subsequent builds, as I insisted (sort of) to leave the test configuration untouched and to get the administrators to kill the process or bounce Bamboo, they failed:

I had a talk with Andrew Calafato last night and understood the queues and how MuleForge's Bamboo schedules the builds. At the moment, the chance of two functional tests having a clash on port occupation is fairly low. In spite of that, after some quick thoughtful moment, I decided to change the ports simply to avoid that situation to happen one day.

The ports should be around 149XX, e.g. 60504 to 14904, 8080-8081 to 14980-14981.

I think.. now, that's better.

- yc

JIRA Transport 1.0 Released

This news item is to announce that version 1.0 of JIRA Transport was officially released yesterday. Please see Release Notes - Latest for the latest release notes.

Many people have written and argued about how evil static methods are, especially when it comes to unit testing. I had spent some time scratching my head last night to get one of the failed tests green.

expected:<6> but was:<2>
junit.framework.AssertionFailedError: expected:&6& but was:&2&
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:282)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:201)
	at junit.framework.Assert.assertEquals(Assert.java:207)
	at org.mule.providers.jira.ConstantsTestCase.testGetSoapPublicMethods(ConstantsTestCase.java:36)

The horrible things behind it are:

1. The test checks if the static methods in the Constants class pick up properties from the System.
2. The static methods lazy-load static variables
3. The reading of properties relies on MuleManager (another singleton)

The test passed if it was run individually but failed if run together with other test cases in a batch. What puzzled me was that I wasn't aware of MuleManager, only after seeing another failed build after smartly introducing a Constants.resetLazyLoaded(). That basically means, MuleManager was instantiated by other test cases and since it was state-ful, my test failed.

(No, I did not write any test suites which was why the test worked on my machine but not on Bamboo. )

In the end, I applied this fix to the test case:

protected void tearDown() throws Exception
    {
        super.tearDown();
        if (MuleManager.isInstanciated())
        {
            MuleManager.getInstance().dispose();
            MuleManager.setInstance(null);
        }
        MuleManagerUtils.setMuleManager(null);
        Constants.setConstantsHelper(null);
    }

Meh.

- yc