Enterprise Integration Zone is brought to you in partnership with:

Pascal is a senior JEE Developer and Architect at 4Synergy in The Netherlands. Pascal has been designing and building J2EE applications since 2001. He is particularly interested in Open Source toolstack (Mule, Spring Framework, JBoss) and technologies like Web Services, SOA and Cloud technologies. Specialties: JEE XML Web Services Mule ESB Maven Cloud Technology Pascal is a DZone MVB and is not an employee of DZone and has posted 56 posts at DZone. You can read more from them at their website. View Full User Profile

Unit testing with Mule ESB 3.4 Enterprise Edition

  • submit to reddit

There is a big chance that when you are using the Mule ESB EE as your ESB implementation and you are creating functional/unit tests you sooner or later will need a license on your test classpath to be able to run Mule in your unit tests. Luckily this isn’t very hard to accomplish. You can just take the license file that is generated when installing your license at the (standalone) server. You can find the license file on the server here: $MULE_HOME/conf/muleLicense.lic. Just copy it to your
‘$PROJECT_HOME/src/test/resources/’ folder so it an be accessed on the classpath.
Till so far fo the happy scenario. However after doing this I ran into the following exception

Caused by: java.lang.ClassNotFoundException: com.mulesource.licm.LicenseKeyException

This is quite scary since I am using Mule EE 3.4.1 and the package name ‘com.mulesource’ has been changed to ‘com.mulesoft’ since Mule v3.1 several years ago!

It appears that adding the following dependency fixes this:<dependency>


And while we are on it I also added the following to solve another issue:<dependency>


With these two dependencies I was able to run my test classes using the EE transports of Mule. Of course you have to make sure the licm.jar is available in the Maven Repo. I described here how to do that.

Published at DZone with permission of Pascal Alma, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)