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.
(more…)
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.
(more…)
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:
- Copy the input test-file to the predefined folder so it is picked up by the test instance of our Mule ESB
- Have Citrus listen on a predefined HTTP port to receive the XML message over HTTP
- Reply to the received message with a predefined XML message
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 .
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.
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.
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). (more…)