A couple of months back we released Mule 3.2, which is the version we recommend for all Mule users. The latest release of Mule 3.2 is Mule 3.2.1 which can be found on the download page.
We haven’t stopped though. Since releasing Mule 3.2.1, we’ve been busy working on Mule 3.3 M1. This is the first of a number of monthly milestones we will be making available to the community on the road towards Mule 3.3. In this blog post I’ll not only go over what’s new in M1, but also give you an idea of what we have planned for Mule 3.3.
Why Mule 3.3?
Mule 3.2 was a great release with a lot of good stuff overall, including new features in the community edition and valuable new enterprise capabilities in the enterprise edition (such as clustering and root-cause analysis), so you might be wondering how we are planning to improve on Mule 3.2
While Mule 3.0 greatly improved usability with the introduction of Flows, we want to further improve the usability of Mule in order to: (1) make things even simpler for existing users; and (2) bring new users into the fold so that they can benefit from all that Mule has to offer.
Before starting on Mule 3.3, we scoured our user forum and jira and talked to a number of Mule users as well as our support team in order to determine where users and customers have the most usability issues with Mule. We then prioritized this information and used it to drive the development of Mule 3.3. The top 5 were the following:
- Error Handling: Make common error handling much easier to configure and use and reduce the need for custom strategies.
- Mule Expressions: Make Mule expressions more consistent, easier to use, and more powerful.
- Iterating over items in a message: Provide support for iterating over parts of a message.
- Upgrade of key third party libraries: Spring and CXF.
- Mule Message Properties: Ensure consistency of behavior in all circumstances.
Of course, this list is by no means exhaustive and some of these issues have multiple facets, but it gives you a very good idea of where we will be focusing our work with Mule 3.3. Another thing we’ll be working on is to continuously improve our documentation.
What’s in Milestone 1?
CXF Upgrade
CXF has been upgraded to version 2.5.0. Apache CXF is the framework used at the core of Mule’s Web Services functionality. CXF 2.5.0 is not only more mature than previous versions but includes a number of new features:
- JIBX Databinding
- WS-SecurityPolicy support for SAML tokens
- Transformation feature that provides for a fast and effective way to transform inbound and/or outbound XML messages
- New Security Token Service
- New WS-Notification Service and API’s
CXF 2.5.0 also now uses WSS4J 1.6, which has:
- SAML2 support
- Performance improvement
- Support for Crypto trust-stores
Mule 3.2 used version 2.3.1, so this is an important and significant upgrade. The work done for Milestone 1 was primarily the version upgrade itself. Watch out for blog posts and additional work in further milestones–both of which will help you understand how to leverage some of these new features.
Note: Since this work, CXF has released version 2.5.1 that includes over 75 additional bug-fixes, and an upgrade to this version has already been made for Milestone 2.
Error Handling
We’ll be giving error handling a lot of love in Mule 3.3 and what’s in M1 is just the start. We’ve decided to take a pattern-based approach and implement new pattern-specific exception strategies. These new exception strategies will make it very easy to define how you want to handle errors in your flows and will significantly reduce the need for custom exception strategies.
‘Catch’ Exception Strategy
This is a new pattern for error handling which allows users to catch an exception thrown during processing and perform alternative processing before optionally returning a response. Previously, it was only possible to implement this pattern using a custom exception strategy.
In the above example, let’s consider what happens if Component1 throws an exception during execution:
- Component2 will not be executed.
- The exception thrown by Component1 is caught by the Flow.
- The catch-exception-strategy handles the exception.
The catch-exception-strategy does the following:
- ExceptionHandlingComponent and any other nested processors are invoked.
- Returns the result of processing of nested processors to the inbound endpoint.
- Does not re-throw the exception.
The fact that this exception strategy handles the exception and does not re-throw it means that the inbound endpoint is unaware that an exception occurred. With http this means an ‘OK’ response code will be returned and with one-way inbound endpoints such as File, FTP, JDBC and JMS, the inbound message is not rolled back in any way.
For more about error handling, you can find documentation here. In parallel to this work, you may have noticed that we have put together some blog posts on getting the most out of error handling and implementing error handling patterns in Mule 3.2.
There will be more error handling patterns in M2! Look out for design proposals with configuration mock-ups on the Mule Developer Forum.
Regex Expression Evaluator
We added a regular expression expression evaluator that can be used anywhere a mule expression is permitted to extract a value from the payload using a regular expression.
In the above example the regular expression matches and returns the order type found in the order message shown. This value is then set as a variable (invocation property) on the message. The variable is then used to route the message based on order type. In this simple example, we simply log the message after routing, but in real life you would route the message for continued processing.
Other
For those interested in the internals for M1 we did some cleanup of the way session properties are stored and accessed to increase consistency of behavior (MULE-5901, MULE-5903) as well as some refactoring to the TransactionTemplate to better support the new error handling use cases (MULE-5911).
We need you!
Want to help with Mule 3.3? Here are a number of things you can do:
- Download 3.3 M1 and use it. Provide feedback via the Mule User Forum (it’d be helpful if you use a “[MULE 3.3]” prefix) or create a JIRA issue if you find a bug.
- Talk to us. Do you think we are focusing on the right areas to improve Mule usability or missing something important? Tell us! Use the Mule User Forum or comment on this blog post.
- Review design proposals. As we work on improvements we’ll be putting together design proposals for review and posting them to the Mule Developer Forum. If you have feedback, please respond. We’ll take all feedback into account as it is very valuable to us. Here is an example post.
- Contribute Code. Think something needs to be in 3.3 and don’t want to wait for us to get to it? Feel free to take things into your own hands and have a go at it yourself and then file a patch. To ensure we integrate your patch speedily you’ll want to make sure you: i) explain well what your patch is for; ii) include a good quality test case; and iii) don’t break any backwards compatibility.
