I am sure you remember your mother telling you to clean your room when you were little. This usually involved taking out the hoover (or the vacuum cleaner for the Yahoos) and getting on with the job.

Fast forward a few years and switch to PostgreSQL. It is very good idea to turn on the auto_vacuum parameter or vacuum the tables manually every few days. If you do not do that, you may end up with a database with just a few tens of thousands of rows occupying over 4.5 GB on the hard drive.

We are going to start using the theory of constraints to control our projects; I believe we have more resources than we need. I am hoping to prove that we can either all finish at four o’clock every day or take on more work and earn more money.

If you are interested, check out Wikipedia. I will send charts that display the buffer consumption and the feeder buffer consumption in a few weeks’ time. You will see just how easy it is to control all your projects.

We are playing around with the JBoss application server 4.2.2GA and Spring JMS. The whole setup is very simple; assuming you want to use a JMS queue, you need to configure it in JBoss and then use the new Spring 2.5 jms namespace.

Let’s begin with the JBoss configuration. You need to drop the *-service.xml file into $SERVER_DIR/deploy/jms. The contents of the file define the destinations and queue names; the file we will show here includes two queues.

<server>
  <mbean code=”org.jboss.mq.server.jmx.Queue”
	 name=”jboss.mq.destination:service=Queue,name=invoice-data”>
    <depends optional-attribute-name=”DestinationManager”>
        jboss.mq:service=DestinationManager
    </depends>
    <depends optional-attribute-name=”SecurityManager”>
        jboss.mq:service=SecurityManager
    </depends>
    <attribute name=”MessageCounterHistoryDayLimit”>-1</attribute>
    <attribute name=”SecurityConf”>
      <security>
        <role name=”guest” read=”true” write=”true”/>
        <role name=”publisher” read=”true” write=”true” create=”false”/>
        <role name=”noacc” read=”false” write=”false” create=”false”/>
      </security>
    </attribute>
  </mbean>

Next, we define the Spring queueConnectionFactory and jmsTemplate beans, as shown in the following context file

<beans>
…
    <jee:jndi-lookup jndi-name=”java:ConnectionFactory”
        id=”queueConnectionFactory” expected-type=”javax.jms.ConnectionFactory”/>
    <bean id=”jmsTemplate” class=”org.springframework.jms.core.JmsTemplate102″>
        <property name=”connectionFactory” ref=”queueConnectionFactory”/>
    </bean>
    <jms:listener-container
        connection-factory=”queueConnectionFactory”
        concurrency=”10″>
        <jms:listener destination=”invoice-data”
             ref=”mdb” method=”mdbMethod”/>
    </jms:listener-container>
…
</beans>

The mdb bean refers to a standard POJO with the mdbMethod. The signature of the mdbMethod follows pattern void mdbMehtod(argument). Now, depending on the type of the message, the argument is either the object we send in ObjectMessage or String if we send TextMessages.

In our Spring 2.5 flagship project, we have chosen to use JUnit 4 and its constraint-based asserts. This is similar to how you write mock objects using the jMock library.

In short, the assertions take form of assertThat(T t, Constraint<T>). The Constraint<T> is an interface that the framework calls to validate the value t.

To get started, download JUnit (4.4) and jMock, unzip the downloaded file and jump straight into writing a test.

import static org.junit.Assert.assertThat;
import org.junit.Test;

public class InvoiceTest {

    @Test public void testAddLine() {
        Invoice invoice = new Invoice();
        InvoiceLine line = new InvoiceLine();
        invoice.addLine(line);
        assertThat(line, org.hamcrest.collection.IsIn.isIn(invoice.getLines()));
    }

}

So here you have it. Your first test using JUnit jMock-style constraints rather than TestCase.assertXXX calls.