In my previous post I described how you can setup Spring and Hibernate in combination with the MongoDB. In this post I show you how you can write your unit test for this setup including a workaround for the fact that there isn’t an embedded version of MongoDB.

Of course you can check manually if your code works by checking the content of the MongoDB. You can use the MongoDB shell or the REST interface by using ‘curl’ (when using REST make sure you start the database with the ‘–rest’ option). For example see the result of curl 'http://localhost:28017/redstream/logItem/'

pascal@~$ curl ‘http://localhost:28017/redstream/logItem/’
{
“offset” : 0,
“rows”: [
{ "_id" : { "$oid" : "4e1c2ffca0eee881985e04f0" }, "_class" : "nl.redstream.mongo.entity.LogItem", "message" : "just some text 0" } ,
{ "_id" : { "$oid" : "4e1c2ffda0eee881985e04f1" }, "_class" : "nl.redstream.mongo.entity.LogItem", "message" : "just some text 1" } ,
{ "_id" : { "$oid" : "4e1c2ffda0eee881985e04f2" }, "_class" : "nl.redstream.mongo.entity.LogItem", "message" : "just some text 2" } ,
{ "_id" : { "$oid" : "4e1c4289a0ee3d15a8af39d3" }, "_class" : "nl.redstream.mongo.entity.LogItem", "message" : "just some text 0" }
],
“total_rows” : 3 ,
“query” : {} ,
“millis” : 0
}
pascal@~$

However, when building software you want your test to be performed automatically so we use JUnit to perform the tests and checks. And I use JUnit to start and stop my local MongoDB instance. Here is how it works (I assume you have the same project setup as I created in my previous post):

• Wire the Spring beans in your test context

I created a SpringContext class for testing purposes:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

package nl.redstream.mongo;   import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext;   /** * Only to be used in test classes!! * * @author pascal */ public class MyTestApplicationContext {   private static MyTestApplicationContext testContext = null;   ApplicationContext context = null;   private MyTestApplicationContext() { }   public static MyTestApplicationContext getInstance() { if (testContext == null) { testContext = new MyTestApplicationContext(); testContext.initialise(); } return testContext; }   public void initialise() { context = new ClassPathXmlApplicationContext( new String[]{"spring-config.xml"}); }   public Object getBean(String name) { return context.getBean(name); }   public ApplicationContext getSpringContext() { return context; } }

With this class I can access my Spring beans easily in my Unit tests.

• Write the test class

I use ProcessBuilder to start and stop the local MongoDB instance before the test class is executed. The base Testclass looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

package nl.redstream.mongo;   import org.apache.log4j.Logger; import org.junit.After; import org.junit.AfterClass; import org.junit.Before; import org.junit.BeforeClass;   public class MongoDBTest {   private static final Logger logger = Logger.getLogger(MongoDBTest.class); static Process p = null;   @Before public void setUp() throws Exception { //@Todo Run mongo with a test specific .js file to produce initial data state }   @After public void tearDown() throws Exception { //@Todo Drop database }   @BeforeClass public static void beforeClass() throws Exception { String[] command = new String[]{"/Users/pascal/development/mongodb-osx-x86_64-1.8.2/bin/mongod", "--dbpath", "/Users/pascal/development/mongodb/data", "--rest"};   ProcessBuilder pb = new ProcessBuilder(command);   p = pb.start();   logger.debug("Process started with pid: " + p);   }   @AfterClass public static void afterClass() throws Exception { // Stop mongod process boolean processClosed = false;   Thread.sleep(500); if (p != null) { while (!processClosed) {   try { p.destroy(); processClosed = true; Thread.sleep(500); logger.info(" Process destroyed: " + p.exitValue()); } catch (IllegalThreadStateException itse) { logger.warn(itse); processClosed = false; } } } } }

And the actual test class:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

package nl.redstream.mongo;   import junit.framework.Assert; import nl.redstream.mongo.entity.LogItem; import nl.redstream.mongo.services.LogService; import org.apache.log4j.Logger; import org.bson.types.ObjectId; import org.junit.Before; import org.junit.Test;   public class LogServiceTest extends MongoDBTest {   private static final Logger logger = Logger.getLogger(LogServiceTest.class); private LogService<LogItem> service = null;   @Test public void testCreateAndFindLog() throws Exception {   ObjectId id = null;   for (int i = 0; i < 3; i++) { LogItem log = new LogItem(); log.setMessage("just some text " + i);   id = service.add(log); logger.debug("log.id = " + id); }   LogItem logFound = service.get(id); logger.debug("log = " + logFound.toString()); Assert.assertNotNull(logFound); }   @Before public void setUp() throws Exception { logger.info("setting up test"); super.setUp(); service = (LogService<LogItem>) MyTestApplicationContext.getInstance().getBean("logService"); //@TODO Run mongo with a test specific .js file to produce initial data state } }

• Run it!

The test output shows it ran successfully:

——————————————————-
T E S T S
——————————————————-
Running nl.redstream.mongo.LogServiceTest
DEBUG [main] nl.redstream.mongo.MongoDBTest: Process started with pid: java.lang.UNIXProcess@603b1d04
INFO [main] nl.redstream.mongo.LogServiceTest: setting up test
DEBUG [main] nl.redstream.mongo.services.MongoDBLoggerServiceImpl: Adding a new LogItem instance
DEBUG [main] nl.redstream.mongo.LogServiceTest: log.id = 4e2fc241a0eea3de77684fdf
DEBUG [main] nl.redstream.mongo.services.MongoDBLoggerServiceImpl: Adding a new LogItem instance
DEBUG [main] nl.redstream.mongo.LogServiceTest: log.id = 4e2fc241a0eea3de77684fe0
DEBUG [main] nl.redstream.mongo.services.MongoDBLoggerServiceImpl: Adding a new LogItem instance
DEBUG [main] nl.redstream.mongo.LogServiceTest: log.id = 4e2fc241a0eea3de77684fe1
DEBUG [main] nl.redstream.mongo.LogServiceTest: log = LogItem [id=4e2fc241a0eea3de77684fe1, message=just some text 2, timestamp=null]
INFO [main] nl.redstream.mongo.MongoDBTest: Process destroyed: 12
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.798 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

There is definitely room for improvement, like adding the possibility to run ‘.js’ scripts to set the database in a predefined state in the @Before method of the test class and remove the database in the @After method.
Another thing that bothered me is the ‘Thread.sleep’ that I had to add at some places to make it work. Nevertheless I showed how to setup a basic test case with MongoDB/Spring combination and if you have a better solution please let me know!

One of the requirements we have for one of our Mule ESB implementations is to log the messages that went through the ESB (especially handy during development and testing). There has been written a lot already about logging with Mule so I am not going to discuss that again. In this post I’ll only show you how you can use Spring/Hibernate and MongoDB to store your messages in the MongoDB, because a document-oriented database like MongoDB is a nice fit for this requirement.

The first thing to do is to install MongoDB on your machine (unfortunately it is not yet possible to run it embedded so we use a local instance instead). For installation see this.

After MongoDB is installed we can create a new standard Maven project and modify the generated pom.xml to the following pom.xml.

Next step is the creation of the Hibernate Entity class like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package nl.redstream.mongo.entity;
 
import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;
import org.bson.types.ObjectId;
 
/**
 * Model object 
 * @author pascal
 */
@Entity
@Table(name = "logItems")
public class LogItem implements Serializable {
 
    @Id
    private ObjectId id;
    private String message;
    private String timestamp;
 
    public ObjectId getId() {
        return id;
    }
 
    public void setId(ObjectId id) {
        this.id = id;
    }
 
    public String getMessage() {
        return message;
    }
 
    public void setMessage(final String message) {
        this.message = message;
    }
 
    public String getTimestamp() {
        return timestamp;
    }
 
    public void setTimestamp(final String timestamp) {
        this.timestamp = timestamp;
    }
 
    @Override
    public String toString() {
        return "LogItem [id=" + id + ", message=" + message + ", timestamp=" + timestamp + "]";
    }
}

As you might notice I have used the ObjectId as primary Id. I was forced to this by bug DATADOC-176 which only recently got fixed.

The Dao and Service object classes that are used to access the MongoDB are:

• BaseDao.java
• AbstractBaseDao.java
• LogItemDaoImpl.java
• LogService.java
• MongoDBLoggerServiceImpl.java

Now wire this all together with the following spring config files:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation=
               "http://www.springframework.org/schema/beans
                http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
 
    <import resource="spring-mongodb-config.xml"/>
 
    <bean id="logService" class="nl.redstream.mongo.services.MongoDBLoggerServiceImpl">
        <property name="dao" ref="logDao"/>
    </bean>
    <bean id="logDao" class="nl.redstream.mongo.dao.LogItemDaoImpl">
        <property name="mongoTemplate" ref="mongoTemplate"/>
    </bean>
</beans>

and the ‘spring-mongodb-config.xml’ (as described here):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:mongo="http://www.springframework.org/schema/data/mongo"
       xsi:schemaLocation=
               "http://www.springframework.org/schema/beans
                http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                http://www.springframework.org/schema/data/mongo
                http://www.springframework.org/schema/data/mongo/spring-mongo-1.0.xsd">
 
    <!-- Default bean name is 'mongo' -->
    <mongo:mongo host="localhost" port="27017">
        <!-- OPTIONAL: configure <mongo:options /> -->
    </mongo:mongo>
 
    <mongo:db-factory dbname="redstream" mongo-ref="mongo"/>
 
    <bean id="mongoTemplate" class="org.springframework.data.document.mongodb.MongoTemplate">
        <constructor-arg ref="mongoDbFactory"/>
    </bean>
</beans>

That’s it. Now you have a foundation to start using MongoDB with Spring and Hibernate classes. In the next post I will show how you can test this setup without manually having to start and stop MongoDB.

As promised I’m going to show a test case for which I have used Citrus to implement it. The case is like this:
In a predefined folder on a machine a character-separated file is placed. This file is picked up by our Mule ESB application. The content is transformed to XML and this XML document is posted to another application over HTTP. This application responds with XML document telling the document was processed correctly.
To test this interface with Citrus we have to perform the following steps:

1. Copy the input test-file to the predefined folder so it is picked up by the test instance of our Mule ESB

Our Mule ESB will poll a directory each second to check if there is placed a new file to process. Our test case starts by having Citrus putting a test file in the directory .

2. Have Citrus listen on a predefined HTTP port to receive the XML message over HTTP

Inside our Mule ESB the file is transformed to XML message and posted on a HTTP port to be processed by the ‘ORDER’ system. We have configured Citrus to listen on this specific HTTP port to pick up the XML message.

3. Reply to the received message with a predefined XML message

This steps mimics the ‘ORDER’ system as it would normally process the incoming XML message and respond with another XML message. In this case Citrus will send back a predefined XML message as response.

The citrus-config.xml for this test case can be found here. I will explain the content of the config file next:

1
2
3
4
5
6

<bean id="citrusJMSConnectionFactory"
         class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="vm://localhost:61616" />
        <property name="userName" value="user"/>
        <property name="password" value="password"/>
</bean>

This part defines a ‘in-memory’ JMS provider to be used by Citrus. We will see later how we use it to check the incoming HTTP request (as described here in the Citrus reference guide).

1
2
3
4
5
6
7

<bean id="namespaceContextBuilder" class="com.consol.citrus.xml.namespace.NamespaceContextBuilder">
        <property name="namespaceMappings">
            <props>
                <prop key="ns1">http://www.redstream.nl/invoice</prop>
            </props>
        </property>
</bean>

Here we define the namespaces that are used in the xml messages in our test. We will use this namespace in the test to check values of certain XML elements.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<bean name="redstreamIntegrationTests"
         class="com.consol.citrus.TestSuite">
        <property name="tasksBefore">
            <list>
                <bean class="com.consol.citrus.actions.ExecuteSQLAction">
                    <property name="dataSource" ref="rsDataSource"/>
                    <property name="statements">
                        <list>
                            <value>DELETE FROM RS_LOGS</value>
                        </list>
                    </property>
                </bean>
            </list>
        </property>
</bean>

With this part I have Citrus clean up my log table in the database of my Mule ESB. We log all incoming and outgoing messages in our ESB to the database.

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- manadatory if XML files are used in a test -->
<bean id="xmlMessageValidator" class="com.consol.citrus.validation.xml.DomXmlMessageValidator"/>
    <bean id="schemaRepository"
           class="com.consol.citrus.xml.XsdSchemaRepository">
        <property name="schemas">
            <list>
                <bean class="org.springframework.xml.xsd.SimpleXsdSchema">
                    <property name="xsd"
                               value="classpath:schemas/rs_invoice_0.3.xsd"/>
                </bean>
            </list>
        </property>
</bean>

When you want to work with XML messages in your test (and that is very likely nowadays) you will need to define an ‘xmlMessageValidator’. And to be able to validate the message against an XML schema you will need to define the schemas in the ‘schemaRepository’ as I have done here.

1
2
3
4
5
6
7

<bean id="rsDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="url" value="jdbc:oracle:thin:@test-vm:1521:XE"/>
        <property name="username" value="user"/>
        <property name="password" value="password"/>
        <property name="driverClassName" value="oracle.jdbc.xa.client.OracleXADataSource"/>
        <property name="removeAbandoned" value="true"/>
</bean>

This is the datasource that Citrus can use to access the database that is used by our Mule ESB application. We use this datasource to clean up the logtable and can use it to perform validations after messages have been processed.

1
2
3
4
5

 <citrus:message-channel-sender id="invoiceFileSender" channel="fileOutboundChannel"/>
<file:outbound-channel-adapter id="invoice-files-out" channel="fileOutboundChannel"
        directory="file://Volumes/staging/invoice" filename-generator="test-filename-generator" />
<bean id="test-filename-generator" class="nl.redstream.citrus.TestFileNameGenerator" />
<si:channel id="fileOutboundChannel" />

This is a mix of Citrus with spring-integration configuration. With this configuration I am able to send files to my test VM with Citrus. It also shows how easy it is to mix Citrus with spring-integration.

1
2
3
4
5
6
7

<!-- receive Invoice HTTP request -->
<citrus-http:server id="orderHttpServer"
               port="8060"
               uri="/services/post-invoice"
               deamon="false"
               message-handler="jmsForwardingMessageHandler"
               auto-start="true"/>

Definition of the HTTP Server in Citrus which listens on port 8060 for a request of our Mule ESB.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

 <bean id="jmsForwardingMessageHandler"
         class="com.consol.citrus.adapter.handler.JmsConnectingMessageHandler">
        <property name="destinationName" value="Citrus.order-response"/>
        <property name="connectionFactory" ref="citrusJMSConnectionFactory" />
        <property name="replyTimeout" value="6000"/>
    </bean>
 
    <!-- Process all received requests -->
    <citrus:jms-sync-message-receiver id="orderRequestReceiver"
                            destination-name="Citrus.order-response"
                            connection-factory="citrusJMSConnectionFactory" />
    <citrus:jms-reply-message-sender id="orderResponseSender"
                            reply-destination-holder="orderRequestReceiver"
                            connection-factory="citrusJMSConnectionFactory" />

THis part forwards the incoming HTTP request to a JMS endpoint. In our test we can perform tests on this incoming JMS message and check if it is valid.

Next thing I want to explain is the test-config.xml itself. I think it is quite self-explainatory:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

<?xml version="1.0" encoding="UTF-8"?>
<spring:beans xmlns="http://www.citrusframework.org/schema/testcase"
              xmlns:ws="http://www.citrusframework.org/schema/ws/testcase"
              xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://www.springframework.org/schema/beans
              http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                  http://www.citrusframework.org/schema/ws/testcase
                  http://www.citrusframework.org/schema/ws/testcase/citrus-ws-testcase.xsd
                  http://www.citrusframework.org/schema/testcase
                  http://www.citrusframework.org/schema/testcase/citrus-testcase.xsd">
 
    <testcase name="Testcase001Test">
        <meta-info>
            <author>Redstream Development Team</author>
            <creationdate>2011-04-24</creationdate>
            <status>DRAFT</status>
        </meta-info>
 
        <description>Tests Testcase001</description>
 
        <actions>
            <send with="invoiceFileSender">
                <message>
                    <resource file="classpath:data/testcase001.txt"/>
                </message>
            </send>
            <receive with="orderRequestReceiver">
 
                <message schema-validation="true">
                    <validate path="//ns1:post-invoice/ns1:CompanyCode" value="1"/>
                    <validate path="string:count(//ns1:post-invoice/ns1:InvoiceLine/ns1:DocID)" value="3"/>
                </message>
                <header>
                    <element name="rs_address" value="order-purchase-invoice-queue" />
                </header>
                <extract>
                    <message path="count(//ns1:post-invoice/ns1:InvoiceLine/ns1:DocID)" variable="${nrOfInvoiceLines}"/>
                </extract>
            </receive>
 
            <echo>
                <message>${nrOfInvoiceLines}</message>
            </echo>
            <send with="orderResponseSender">
                <message>
                    <resource file="classpath:data/response-testcase001.xml"/>
                </message>
            </send>
        </actions>
    </testcase>
</spring:beans>

The first action that is done is sending a file to my Mule ESB. The next step is that I wait for the response from my ESB. When I received that I check the contents of XML message at some points and check if it is valid against the schema.
Then after echoing the number of invoice lines I have Citrus return the HTTP request with a fixed XML response so the Mule ESB ends this action successfully.
That completes this example of how to use Citrus to test your ESB implemention. I hope it is more clear now how you can use Citrus for your (automated) integration tests with this real life example.

This post describes how we managed to use standalone ActiveMQ (v5.2.0) as JNDI datasource in our Mule ESB application deployed in Apache Tomcat(v6.0). If you are still with me after reading this first line then I may assume you know your way in this part of the Java open-source world :-)
Here is the situation:
We have deployed a number (about 10) of Mule applications as WAR’s in our Tomcat installation. Each WAR is using the same standalone ActiveMQ instance as JMS provider. We implemented this by defining an ActiveMQ connector in each WAR (actually in a separate JAR that is included in each WAR).

However, recently we defined our database datasource as a JNDI resource in Tomcat. The big advantage is that it is only configured in just one place and maintained by the container instead of each WAR creating its own pool of connections.
So we decided we could do the same for the ActiveMQ datasource (actually I was triggered by this article).

So here are the steps we took to make this work:

1. Define a global resource in server.xml of the Tomcat instance:

1 2 3 4 5 6 7 8 9 10

<Resource name="jms/ConnectionFactory" auth="Container" type="org.apache.activemq.ActiveMQConnectionFactory" description="JMS Connection Factory" factory="org.apache.activemq.jndi.JNDIReferenceFactory" brokerURL="tcp://localhost:61616" brokerName="myActiveMQBroker" userName="user" password="password" />

2. Define a global resourceLink in the context.xml of the Tomcat instance:

1 2	<ResourceLink name="jms/myJMS" global="jms/ConnectionFactory" type="org.apache.activemq.ActiveMQConnectionFactory" />

3. Add to necessary libs to your /TOMCAT_HOME/lib directory:

For your Tomcat instance to be able to work with the standalone ActiveMQ it must have loaded the necessary classes on its classpath. To make this possible you should copy the jar activemq-all-5.2.0.jar into your $TOMCAT_HOME$/lib directory.

These are the steps to setup Tomcat. Now you have to tell your Mule application it has to access this datasource instead creating its own pool. For this add the following to your Mule config:

• Define your (Spring) datasource:

1 2 3

<bean id="activeMqConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/jms/shipJMS"/> </bean>

• Define the activeMQ connection like this:

1 2 3 4 5 6 7 8 9 10 11 12

<jms:activemq-connector name="JMSConnector" specification="1.1" dynamicNotification="true" connectionFactory-ref="activeMqConnectionFactory" acknowledgementMode="AUTO_ACKNOWLEDGE" maxRedelivery="3" disableTemporaryReplyToDestinations="true" persistentDelivery="true"> <custom-exception-strategy class="nl.redstream.exceptionhandlers.DefaultConnectorExceptionHandler" enableNotifications="true"> <vm:outbound-endpoint connector-ref="vmConnector" path="error-handler" /> </custom-exception-strategy> <ee:retry-forever-policy frequency="30000"/> </jms:activemq-connector> </ul>

In the next post I show how to config your unit tests to work with this configuration

]]> http://www.redstream.nl/2011/01/17/combining-activemq-tomcat-and-mule-esb/feed/ 0