In Maven, plugins can be coupled to a Maven lifecycle phase and the configuration can be stored in your pom.xml. This is very convenient if you would like to perform some extra steps when, for example, you are deploying a web application.

But, what if you would like to execute a specific goal of a plugin and use the configuration in your pom.xml?

As an example, I’ll use the wagon-maven-plugin plugin. The plugin is used to copy a number of XSL stylesheets to a target environment when deploying a web application. In the following snippet, you’ll see that the execution of the plugin is coupled with the deploy phase.

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

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>wagon-maven-plugin</artifactId>
    <version>1.0-beta-3</version>
    <executions>
        <execution>
            <id>upload-xsl</id>
            <phase>deploy</phase>
            <goals>
                <goal>upload</goal>
            </goals>
            <configuration>
                <serverId>${mule.deploy.serverId}</serverId>
                <fromDir>src/main/resources/xsl</fromDir>
                <includes>**/*.xsl</includes>
                <url>${mule.deploy.url}</url>
                <toDir>${mule.deploy.xsl.toDir}</toDir>
            </configuration>
        </execution>
    </executions>
</plugin>

The used configuration will only be in effect when the plugin is executed as a result of the deploy phase. When executing the command mvn clean compile wagon:upload, you’ll be confronted with the message:

1
2
3
4
5
6
7
8
9
10

[INFO] --- wagon-maven-plugin:1.0-beta-1:upload (default-cli) @ demo-project ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.404s
[INFO] Finished at: Mon Oct 31 14:56:18 CET 2011
[INFO] Final Memory: 21M/554M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:upload (default-cli) on project demo-project 
The parameters 'url' for goal org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:upload are missing or invalid -> [Help 1]

The answer lies in the resulting message. It refers to execution Id default-cli. This reserved Id is used when executing Maven goals from the command-line. So, add another execution for the wagon-maven-plugin with id=default-cli and add your most favorite configuration. See following snippet:

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

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>wagon-maven-plugin</artifactId>
    <version>1.0-beta-3</version>
    <executions>
        <execution>
            <id>upload-xsl</id>
            <phase>deploy</phase>
            <goals>
                <goal>upload</goal>
            </goals>
            <configuration>
                <serverId>${mule.deploy.serverId}</serverId>
                <fromDir>src/main/resources/xsl</fromDir>
                <includes>**/*.xsl</includes>
                <url>${mule.deploy.url}</url>
                <toDir>${mule.deploy.xsl.toDir}</toDir>
            </configuration>
        </execution>
        <execution>
            <id>default-cli</id>
            <configuration>
                <serverId>${mule.deploy.serverId}</serverId>
                <fromDir>src/main/resources/xsl</fromDir>
                <includes>**/*.xsl</includes>
                <url>${mule.deploy.url}</url>
                <toDir>${mule.deploy.xsl.toDir}</toDir>
            </configuration>
        </execution>
    </executions>
</plugin>

Now you can execute, the maven-wagon-plugin as part of the build process and separate using a CLI command.

Just spent a costly 30 minutes finding out how to create a tgz tarball on OSX Lion without all the hidden ._ files. These files are the result of using the HFS or HFS+ filesystem.

What I got when issuing a tar -zcvf my-package.tar.gz dir1/ was a structure like this:

1
2
3
4
5
6
7
8
9
10
11

.
._dir1
dir1
  ._file1
  file1
  ._file2
  file2
  ._subdir
  subdir
    ._file3
    file3

When extracting this tarball on Linux, you’ll get all the unnecessary ._ files.

To prevent them from being packaged in the first place, issue the following command from your Terminal: export COPYFILE_DISABLE=true

PS: You could make this setting ‘stick’ by adding them to your ~/.bash_profile

The result now will be a nice and clean tarball:

1
2
3
4
5
6

.
dir1
  file1
  file2
  subdir
    file3

In this post I show you how I setup a little test to see if and how easy I could manage to route the traffic to and from a web service through Mule ESB. The business case for this is an issue that one of our customers ran into when using web services. In a program hundreds of calls are done in a relative short period. Most of the time this isn’t a problem but sometimes vague issues occur. To get a better insight in this issue I want to put Mule in the middle so I can log the request and response and hopefully get a better idea about what is sent across the line. This is called the Web Service Proxy pattern and is commonly used to validate and audit the web service calls. For more background info about this pattern see this article.

To get started I downloaded the Mule Standalone edition here and installed it. That isn’t very hard, just untar the thing and set the MULE_HOME property. Go to the bin directory and give ‘./mule’ and off you go (except for a warning when running on MacOS 64-bit, but it doesn’t seem to harm so far…):

To create a test web service I setup a MockService in SoapUI. Like this:

All you need is a WSDL available. I just picked one from a previous project for testing purposes. With this MockService started you can fire your SOAP requests and will receive a (predefined) response from the MockService:

Next step is create a new Mule project (I still favor Maven above the Mule Studio):

• create new Maven project with

mvn mule-project-archetype:create -DartifactId=WSProxy -DmuleVersion=3.1.2

• Set up the WS Proxy

To create WS Proxy I followed the description here
Note: to make use of the pre-defined ‘pattern’ you must add the following dependency to the pom:

1 2 3 4 5 6

<dependency> <groupId>org.mule.patterns</groupId> <artifactId>mule-patterns-all</artifactId> <version>${mule.version}</version> <scope>provided</scope> </dependency>

My Mule config file looks like this:

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

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd http://www.mulesoft.org/schema/mule/pattern http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd"> <description> Proxies a Web Service </description> <custom-transformer name="my-transformer" class="nl.redstream.proxy.wsproxy.MyTransformer" /> <object-to-string-transformer name="ObjectToStringTransformer" />   <pattern:web-service-proxy name="my-order-ws-proxy" inboundAddress="http://Pascal-Almas-MacBook-Pro.local:8090/my-order" responseTransformer-refs="ObjectToStringTransformer my-transformer" outboundAddress="http://Pascal-Almas-MacBook-Pro.local:8088/mockDataServiceSoapBinding" /> </mule>

• Fire up the proxy

To run the Mule application just make sure your Mule installation is running and in your project execute the command ‘mvn clean install’
You should see a message in your Mule console like this:

Now we can put the proxy at work by redirecting the SoapUI request to the url: http://Pascal-Almas-MacBook-Pro.local:8090/my-order. It should the be forwarded to the original url and the translator I put in between should output the content to the Mule console:

However if you try this for the first time big chance you will run into this issue (at least I did). To get around this issue modify the soapUI settings like this:

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.

In a previous post, I mentioned that you could extend the function library in Altova MapForce and add your own functions. In this post I’ll show you (briefly) how to do this using the Java methods from the previous post.

The MapForce documentation only contains a little information on how to add your own custom functions.

The base directory in which you installed MapForce contains a directory called MapForceLibraries. Here, you will find a number of, so called, mff files, which stands for MapForce Functions. Inside, the definition is stored of the functions you are able to select from the library when working on a mapping. We will be using this principle to add an extension of our own. The only thing we need to do, is create such a mff file.

As I already said, the MapForce documentation does not contain a lot of information on this subject. But … what it does include is the XML Schema for the mff file. It is called mff.xsd and it is also located in the MapForceLibraries directory. Open the XML Schema in XMLSpy (or any other XML editor) and select element mapping to get an overview of the library structure. Notice that the XML Schema is well-documented (at least better than the actual MapForce documentation).

We will, briefly, walk through the most important elements. First, element mapping: the root element.

First, element implementations. This element refers to the possible implementations of your extension (e.g. Java, XSLT, C#, etc).

Functions can be grouped, hence the group element. The component element inside describes how your extension should be called. The target describe your input parameters (if any) and output describes your output.

Here’s what an example XML could look like. We used an xslt2 implementation that points to a xslt stylesheet.

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

<?xml version="1.0" encoding="UTF-8"?>
<mapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///C:/Program%20Files/Altova/MapForce2011/MapForceLibraries/mff.xsd" version="8" library="redstream" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mf="http://www.altova.com/MapForce/2010/standard">
	<implementations>
		<implementation language="xslt2">
			<setting name="xsltfilename" value="xlst-redstream-library.xsl"/>
		</implementation>
	</implementations>
	<group name="demo functions">
		<component name="greeting">
			<sources>
				<datapoint name="name" type="xs:string"/>
			</sources>
			<targets>
				<datapoint name="result" type="xs:string"/>
			</targets>
			<implementations>
				<implementation language="xslt2">
					<function name="rs:greeting" namespace="java:nl.redstream.XsltUtils"/>
				</implementation>
			</implementations>
			<description>
				<short>result = 'Hello ' + name + ' !'</short>
				<long>Returns friendly message.</long>
			</description>
		</component>
	</group>
</mapping>

The related XSLT file looks like this:

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

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" 
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:fn="http://www.w3.org/2005/xpath-functions" 
   xmlns:rs="java:nl.redstream.utils.XsltUtils">
 
   <xsl:function as="xs:string" name="rs:greeting">
      <xsl:param as="xs:string" name="name"/>
      <xsl:value-of select="rs:greeting($name)"/>
   </xsl:function>
 
</xsl:stylesheet>

Once, you’ve created your mff and xslt file, copy them into MapForceLibraries directory (make sure MapForce is not running, otherwise you will not be able to write in that directory). Start Altova MapForce, create a new mapping (implemenation xslt2 and behold … your extension will show up in the Library.

Now, you can drag-and-drop the function onto your mapping.

The resulting XSLT will look 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

<?xml version="1.0" encoding="UTF-8"?>
<!--
This file was generated by Altova MapForce 2011sp1
 
YOU SHOULD NOT MODIFY THIS FILE, BECAUSE IT WILL BE
OVERWRITTEN WHEN YOU RE-RUN CODE GENERATION.
 
Refer to the Altova MapForce Documentation for further details.
http://www.altova.com/mapforce
-->
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                                              xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                                              xmlns:fn="http://www.w3.org/2005/xpath-functions" 
                                              xmlns:rs="java:nl.redstream.XsltUtils" exclude-result-prefixes="xs fn rs">
   <xsl:output method="xml" encoding="UTF-8" indent="yes"/>
   <xsl:template match="/">
      <dataset>
         <row>
            <column>
               <xsl:for-each select="dataset/row/column">
                  <xsl:attribute name="name" select="rs:greeting(fn:string(@name))"/>
               </xsl:for-each>
            </column>
         </row>
      </dataset>
   </xsl:template>
</xsl:stylesheet>

Unfortunately, you cannot display the results of the customized mapping in MapForce (#featurerequest). Instead, you could use XMLSpy and use the settings from the previous post.

That’s it … enjoy!

Like I posted before Mulesoft has released a new platform: iPAAS. I just went through the starters guide and I am pretty impressed. Of course the use case in the tutorial is very simple but the whole idea of just putting your Mule config into the cloud and it runs sounds good. And I have seen it working (you can check for yourself by submitting text to this url.
Here is a snapshot of the dashboard you get with you Mule iON account:

Although it looks pretty nice at first sight it does raise questions and some topics for further investigation: what about security and in what use cases will this be the best solution? Mulesoft already has answers to those questions (security and use cases) but I am going to find out myself and let you know my opinion. Stay tuned!

Mulesoft recently released some new products, totally different from each other but both very welcome.
The first one is MuleStudio. Mule Studio is an Eclipse-based developer tool, that allows to graphically create and test Mule ESB Flows. It is currently in beta but I think it might be a good reason to go back to Eclipse. Last few years I have been using Netbeans for my Mule/Java development because I liked the combination between Netbeans and Maven better.

The other ‘product’ that is released is Mule iON. I think a graphical development tool is nice to have but this iON thing is something that can really become big. It makes you use the cloud as the platform for your integration software. They call it the iPAAS (Integration Platform as a Service).

The coming days I will have a look at both and posts my findings here so stay tuned!

Recently, I ran into an open-source test framework called Citrus. Citrus supports you in testing message interfaces in enterprise applications. Manual testing effort as well as coding mocks and simulators are not necessary. Instead Citrus enables integration testing in an automated way with out-of-the-box simulation of various message transports. We’ll use it to test our Mule based ESB.

Mule, of course, offers great possibility to unit test your application. And we also have a test setup which ‘talks’ to other applications. What we didn’t have was a testing environment which we could use to test the ESB as a blackbox without being dependent on other (external) applications. And this is exactly where Citrus comes in. Citrus makes it possible to test the complete lifecycle of a message flow without being dependent of other systems, actually with Citrus you proxy these dependencies.
In this post I will provide details and tips on how to setup and use Citrus. Although the documentation that is available is easy to read, it is not complete. It took me quite some effort to get it all running but like I said before the benefits of this framework are huge.

In the reference guide of Citrus there is a chapter about how to use Citrus with Maven. I use that guide as base and add some info that was missing in my case but is essential to get things working. I use the 1.2-SNAPSHOT edition of Citrus.

I took the following steps to get it running:

1. Add repositories to your settings.xml

To have access to the Citrus jars you need to tell Maven where to get them. You can do this by adding the following repositories to your settings.xml (or even better to Artifactory or similar repository manager):

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

<repositories> [...] <repository> <id>consol-labs-release</id> <url>http://labs.consol.de/maven/repository/</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> <repository> <id>consol-labs-snapshots</id> <url>http://labs.consol.de/maven/snapshots-repository/</url> <snapshots> <enabled>true</enabled> <!-- Policy: always, daily, interval:xxx (xxx=#minutes, 60*24*7=10080), never --> <updatePolicy>10080</updatePolicy> </snapshots> <releases> <enabled>false</enabled> </releases> </repository> [...] </repositories>

2. Add necessary dependencies to your project’s pom

Add the following dependencies to the pom of your project (at least the citrus-core, the others are depending on the tests you want to perform).

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

<dependency> <groupId>com.consol.citrus</groupId> <artifactId>citrus-core</artifactId> <version>1.2-SNAPSHOT</version> <scope>test</scope> </dependency> <dependency> <groupId>com.consol.citrus</groupId> <artifactId>citrus-http</artifactId> <version>1.2-SNAPSHOT</version> <scope>test</scope> </dependency> <dependency> <groupId>com.consol.citrus</groupId> <artifactId>citrus-adapter</artifactId> <version>1.2-SNAPSHOT</version> <scope>test</scope> </dependency>

3. Add necessary plugins to your project’s pom

To generate and execute the Citrus test cases you need to add the Citrus plugins (and extra source path) to your project. This is done by adding the following to your project’s pom:

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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> <encoding>${project.build.sourceEncoding}</encoding> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.2</version> <configuration> <encoding>${project.build.sourceEncoding}</encoding> </configuration> </plugin> <plugin> <groupId>com.consol.citrus.mvn</groupId> <artifactId>citrus-maven-plugin</artifactId> <version>1.1</version> <configuration> <author>Redstream Team</author> <targetPackage>nl.redstream.test</targetPackage> </configuration> </plugin> <plugin> <artifactId>maven-surefire-plugin</artifactId> <configuration> <skip>true</skip> </configuration> <executions> <execution> <id>citrus-tests</id> <phase>integration-test</phase> <goals> <goal>test</goal> </goals> <configuration> <skip>false</skip> </configuration> </execution> </executions> </plugin> </plugins>   <testSourceDirectory>src/citrus/java</testSourceDirectory> <testResources> <testResource> <directory>src/citrus/java</directory> <includes> <include>**</include> </includes> <excludes> <exclude>*.java</exclude> </excludes> </testResource> <testResource> <directory>src/citrus/tests</directory> <includes> <include>**/*</include> </includes> <excludes> </excludes> </testResource> <testResource> <directory>src/citrus/resources</directory> <includes> <include>**/*</include> </includes> <excludes> </excludes> </testResource> </testResources> </build>

4. Create a Citrus Test Case

Next step is to use the Maven plugin to create a new Test Case. Run the command

mvn citrus:create-test

and answer the questions.
Note 1: the name of the testcase is going to be the Java class name so only use the valid characters for a Java class name
Note 2: Make sure the name of the testcase ends with ‘Test’ otherwise the test isn’t found when trying to run it (at least in case you generate a JUnit4 type of test).

5. Add a ‘citrus-context.xml’ to the classpath

This isn’t mentioned in the guide but is a mandatory step: you need to have a ‘citrus-context.xml’ file on the classpath for Citrus to run your tests. Here is a snippet from the config file that can be found in the examples that are delivered with Citrus:

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

<?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:citrus="http://www.citrusframework.org/schema/config" xmlns:citrus-ws="http://www.citrusframework.org/schema/ws/config" xmlns:citrus-http="http://www.citrusframework.org/schema/http/config" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://www.citrusframework.org/schema/config http://www.citrusframework.org/schema/config/citrus-config.xsd">   ... <!-- Message Validators --> <bean id="xmlMessageValidator" class="com.consol.citrus.validation.xml.DomXmlMessageValidator"/>   <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"> <property name="brokerURL" value="${jms.server.url}" /> </bean>   <bean class="com.consol.citrus.variable.GlobalVariables"> <property name="variables"> <map> <entry key="project.name" value="Citrus Greeting sample"/> </map> </property> </bean>   ...   <!-- TestSuite definition --> <bean name="citrus-samples-greeting" class="com.consol.citrus.TestSuite"/> </beans>

When all this is done you can run your test with the command:

mvn clean integration-test -Dtest=YourTestNameTest

In the next posts I will go into more detail about certain Test Scenarios and how to test these with Citrus.

Although the TcpTunnelerGui has been around for a while (for about 10 years now) it is still helping me out in several situations. The only thing I keep forgetting is where to get it and what the exact syntax is to run it. So for future reference I put it in this post (and hope I remember this post…).

1. Download the jar (soap-2.3.jar) containing the necessary classes here
2. Open a command prompt/ terminal and go the location where the jar is located
3. Run the following command

java -classpath soap-2.3.jar org.apache.soap.util.net.TcpTunnelGui 8081 localhost 8080

For more info about the tunneler see here. So, now when I need this tunneler in the future I know where I can find it and how to use it :-)