The other day I helped a customer figure out a little XPath problem: they had an XML document and wanted to process it depending on an XPath expression. Here’s the Mule config that shows what we were trying to achieve:
The new MuleForge works with different project hosting platforms, it is now a repository of all things Mule rather than a project hosting service. I recently migrated the Maven Mule Plugin from our old MuleForge infrastructure to GitHub. This was quite a journey and I had to trawl the web quite a bit to gather all the required steps to make the change. So here’s the full story, in case anyone wants to do the same.
In part 2 of this mini-series I showed a flow that retrieves an RSS feed periodically, splits it and sends each RSS entry via email. In this part I’d like to show how to split up the flow a bit in order to enable unit testing.
To refresh your memory here’s what the flow currently looks like:
Testing this flow is hard if not impossible for a number of reasons:
In my last blog post I showed a simple flow to retrieve an RSS feed periodically, split it and send each RSS entry via eMail. The solution has one major drawback, though: once the Mule application is restarted, Mule has forgotten which feed entries have already been sent. The RSS feed is retrieved again and another bunch of eMails is sent.
The standard EAI pattern for receiving messages only once is the idempotent receiver.
I read a couple of RSS feeds regularly. Unfortunately, I work across a couple of machines: my laptop, the machine in the office, my wife’s laptop. This rules out using a local RSS reader as I’d have to manage the redundant subscriptions let alone I’d have to remember which feed entries I have already read and which one not. Sure, I could use Google’s feed reader but being mostly eMail centric anyway I’d love to see RSS feed entries in my INBOX.
Mule configuration files are Spring XML files by nature. So the XML editor is an important development tool and provides a lot of benefit. When working in Eclipse, it provides:
However,
In order to use the hot deployment feature that was introduced with Mule 3 you need to package your application as a zip file.
If you are using Maven to build your Mule applications then packaging zip files for hot deployment is very easy. All you need is to declare your packaging to be Mule:
The Mule IDE 2.2.1 release that went out today contains a big productivity improvement: a hot deployment builder. It allows you to deploy your project to a running Mule 3 instance automatically. Read all about hot deployment in Mule 3 in the user guide.
The easiest way to get started with the hot deployment builder is to create a new Mule project. It will have the builder attached automatically.
While the rest of the team was still busy with Mule 3 release preparations I took some time to update Mule IDE to be compatible with Mule 3.
I have put most work into creating new projects from the examples that come with the Mule distribution. This feature was rewritten to match the examples layout in Mule 2.2.x as well as in Mule 3. You’ll notice that the entire example is now copied over (minus a few files that do not make sense in an Eclipse project,
When you take a look at the examples that come with the latest Mule 3 milestone release, you’ll notice that endpoints have an exchange-pattern attribute now:
This attribute replaces the synchronous attribute we used before. Why did we change the configuration? The old synchronous attribute was purely a two-way state: it was either true or false. With the exchange-pattern attribute on endpoints we’re free to allow additional values in the future.
