Access Keys:
Skip to content (Access Key - 0)


What's New in this Release?

New Features

This section describes the new features in Mule 2.2.5.

Improved Mule Management Console

The management console for Mule ESB, which was released in October 2009 for the enterprise edition of Mule 2.2.2, has been improved for Mule 2.2.5. The management console has many new features and fixes, in addition to providing support for Mule embedded in WebSphere.

The new features added to the console include the following:

  • Managing and monitoring multiple Mule ESB instances from a single console
  • Fine-grained ESB control capabilities (e.g., restart/stop, dynamically tune services in real time, remote access of files and configurations)
  • Diagnostics and monitoring (detailed diagnostics and resource allocation data)
  • Deep auditing (auditing of message traffic)
  • Dynamic resource allocation for the underlying server (e.g., thread pools)
  • Intelligent alerting capabilities around Mule-specific SLAs
  • Alerts on Mule that execute dynamic scripts

The management console does not support profiling, patch management, or managing versions of Mule prior to 2.1. If you need these features or to manage Mule 1.x instances, use Mule HQ instead. Downloads and documentation for both are available on the MuleSoft customer portal.

Highlights of Mule ESB 2.2.5

  • IBM JDK 1.5 and 1.6 certification
  • Introducing hot-deployment (when deploying as a web app in JBoss 4.x, Tomcat 5.5.x 6.0.x and Tcat Server 6 )
  • Upgraded CXF to 2.1.9
  • Introducing Recipient List Exception Based Router

Recently Added Features

This section describes the features recently added in Mule 2.2

New Mule Management Console

The new management console for Mule ESB has been released in October 2009 for the enterprise edition of Mule 2.2.2. The management console is the next generation of Mule HQ and is based on the updated Hyperic HQ 4.1.2 platform, which has many new features and fixes. The management console also provides support for Mule embedded in WebSphere.

The management console does not support profiling, patch management, or managing versions of Mule prior to 2.1. If you need these features or to manage Mule 1.x instances, use Mule HQ instead. Downloads and documentation for both are available on the MuleSoft customer portal.

New and Improved Mule WMQ Transport

The premium Mule Enterprise transport for IBM® WebSphere® MQ (Mule WMQ transport) has been rewritten with many new features, including:

  • Simplified configuration
  • Support for local, multi-resource, and XA transactions
  • Support for native MQ message types
  • Supports async request-response messaging pattern transparently in both JMS and native MQ message types
  • Support for connection retry policies (self-healing) with or without transactions
  • Support for IBM-specific headers
  • JNDI destination support including JNDI connections
  • Per endpoint control over target clients (native or JMS compliant)
  • Numerous fixes to the discrepancies in behavior between WMQ v6 and v7
  • Certified on WMQ v6 and WMQ v7

For more information, see Mule WMQ Transport in the Mule User Guide (login required).

Stabilized API and Schemas

This release marks the completion of the major rework of the APIs and schemas that started with the 2.0 release. While additional improvements will be made going forward, you will not see the dramatic changes of previous releases. This means that you can upgrade to Mule 2.2 with the confidence that migration to future releases will be much simpler than it has been in previous releases.

For information on using the Migration Tool to migrate your existing files, see the Migration Guide on the Customer Portal (customer login required).

Mule IDE 2.0

The Mule IDE works with Eclipse to make configuring Mule quick and easy. Need to add a new configuration file to your Mule project? Simply select the transports and modules you want to use, and the Mule IDE creates the file for you, complete with namespaces and template tags ready to go. Want to create a new project? Mule IDE sets up the project structure for you and creates all the necessary dependencies. As you add elements to the file, the auto-completion feature in Eclipse makes it simple to add the correct properties without having to look them up. Developing with Mule has never been faster or easier. For more information, see the Mule IDE User Guide.

Enhanced Expression Support

Expressions allow you to extract information from the current message or determine how to handle the message. Expressions are very useful with routers and filters for defining routing logic and for filtering out unwanted messages.

Some filters and routers are designed specifically for using expressions and have unique attributes for specifying the evaluator and the expression. For example, the following filter evaluates the header of each message and picks up messages that have the origin-country property in the header set to "USA":

<expression-filter evaluator="header" expression="origin-country=USA"/>

For other filters, routers, transformers, and properties, you can add expressions using the #[<evaluator>:<expression>] syntax to the attribute where you specify the value, pattern, etc. For example, the following expression adds the ID from the message header using the XPath evaluator:

    <add-property name="GUID" value="#[xpath:/msg/header/ID]/>

For more information on expressions, see Using Expressions in the Mule User Guide (login required).

Expression Language

In Mule 2.2, you can now use the powerful new Mule expression language, which provides a unified language for querying message properties, attachments payload, Mule context information such as the current service or endpoint, and access to the registry. The syntax is #[mule: followed by message, context, or registry, followed by a period and then the object to query or an evaluator followed by the values in parentheses. This syntax maps to the objects in the org.mule.expression package and is useful for querying Mule information at runtime. For example, the following configuration prepends the current service's name and a dash to the Foo property on each message processed by the service:

<rename-message-property key="Foo" value="#[mule:context.serviceName]-Foo"/>

For more information, see Expressions Configuration Reference in the Mule User Guide (login required).

Namespaces in Expressions

Additionally, you can now declare a namespace globally so that it can be used by XPath expressions across Mule. For example, you could specify the foo namespace globally like this:

<mulexml:namespace-manager includeConfigNamespaces="true">
  <mulexml:namespace prefix="foo" uri=""/>

and then use the foo namespace in the following filter:

<expression-filter evaluator="xpath" expression="/foo:purchaseOrder/foo:shipTo/@country = 'US'"/>
When working with Mule XML configurations you should always use a schema-aware XML editor so that you get all the benefits of code complete and the inline documentation that the Mule schemas provide. For example, when entering the <expression-filter> above, you would get a list of possible evaluators and documentation that describes how to define the expression.

For more information, see Expressions Configuration Reference in the Mule User Guide (login required).

Support for Spring Security 2.0

You can now use Spring Security 2.0 as a Security Manager inside of Mule. Spring Security is the next version of Acegi and provides a number of authentication and authorization providers such as JAAS, LDAP, CAS (Yale Central Authentication service), and DAO. You can use any of the library's security providers with Mule.
For example, you could configure a security provider for an in-memory database of users. To configure the provider, you set up a <user-service> element and the <authentication-manager> to which Mule delegates:

  <mule-ss:delegate-security-provider name="memory-provider" delegate-ref="authenticationManager" />

  <ss:authentication-manager alias="authenticationManager" />

    <ss:user-service id="userService">
      <ss:user name="ross" password="ross" authorities="ROLE_ADMIN" />
      <ss:user name="anon" password="anon" authorities="ROLE_ANON" />

For more information, see Configuring Security in the Mule User Guide (login required).

Support for Spring-first Deployments for Mule Embedded in a Webapp

Submitted as a patch by a Mule community user, this feature lets Mule use your existing application context (WebApplicationContext), if it has already been created by Spring, as the parent application context for the Mule configuration builder. This gives Mule easy access to all the beans you've configured in your Spring application context.

For example, you could embed Mule in your webapp as follows:

MuleContext muleContext = new DefaultMuleContextFactory().createMuleContext(); 

ConfigurationBuilder builder = new SpringXmlConfigurationBuilder("spring-beans.xml, mule-config.xml");


As of version 2.2, Mule checks to see if an application context has already been created by Spring, and if there is one, Mule uses it as the parent automatically.

For more information, see Spring Application Contexts in the Mule User Guide (login required).

Multi-resource Transactions

You can now configure multi-resource transactions, which enable a series of operations from multiple JMS resources to be grouped into a single transaction. For more information, see Transaction Management in the Mule User Guide (login required).

Graceful Shutdown

As of Mule Enterprise 2.2.2., the shutdownTimeout attribute allows you to set the time in milliseconds to wait for any in-progress messages to finish processing before Mule shuts down. For more information, see Global Settings Configuration Reference in the Mule User Guide (login required).

SAML Security Module

As of Mule Enterprise 2.2.3, Mule offers support for the Security Assertion Markup Language (SAML), which is a standard for exchange of security information between federated systems. For more information, see in the Mule User Guide (login required).

Certification on HP-UX

Mule Enterprise 2.2 is now certified on the HP-UX platform. For a complete list of the certified platforms, see Installing Mule.

Changed Functionality

Mule 2.2 includes several changes to existing functionality.

Simplified Message Styles

The synchronous messaging style now inherently supports remote synchronous mode, so you no longer have to set the remoteSync attribute on endpoints. For example, the following diagram illustrates how a synchronous message flows. As you see below, Mule always returns the result from the component back to the caller, as well as sending it out via the outbound endpoint.

As of Mule 2.2, you specify the synchronous attribute explicitly on each synchronous endpoint (default is false, creating asynchronous endpoints), which makes your configuration easier to interpret and control when you're using more complex messaging styles. For example, the Async Request-Response messaging style looks like this:

This pattern enables request-response messaging and allows the back-end process to be forked to invoke other services and return a result based on the results of multiple service invocations. The async reply router is used to listen on a Reply To endpoint for results. To configure this style, you must have a synchronous inbound endpoint:

<service name="AsyncRequestResponseService">
    <http:inbound-endpoint host="localhost" port="8080" path="/mule/services" synchronous="true"/>


You use the <async-reply> element to listen on a reply endpoint:

  <async-reply timeout="5000">
    <jms:inbound-endpoint queue="reply.queue"/>

And you must have at least one outbound endpoint:

      <reply-to address="jms://reply.queue"/>
      <jms:outbound-endpoint queue="service1" synchronous="false"/>
      <jms:outbound-endpoint queue="service2" synchronous="false"/>

For more information, see Mule Messaging Styles in the Mule User Guide (login required).

Retry Policy Enhancements

Mule 2.2 supports asynchronous retry policies, so the application does not need to wait for all endpoints to connect before it can start up, and if a connection is lost, the reconnection will happen in a separate thread from the application thread. Additionally, retry policies are now certified on transacted messages and can be used with the FTP, JMS, and JDBC transports.

For more information, see Configuring Retry Policies in the Mule User Guide (login required).

Changed Namespace Paths

The Mule Enterprise schemas are now located on along with the Community Edition schemas instead of on .com. Additionally, the Enterprise schemas include ee in the path and in the schema name. For example, the Mule WMQ transport schema is now located at

Additional Changes

Mule 2.2 also includes an improvement to the CXF transport so that you no longer need to specify the servlet URL to generate the WSDL, and several schema changes. For more information, see Migrating Mule 2.1 to 2.2. Additionally, the following changes have been made:

There are many more improvements in this release, including the following:

  • New XPath extractor transformer, BeanBuilderTransformer transformer, XPath filter, and schema validation filter
  • Fixes for the examples and an overhaul of the Bookstore example to use web services. You can see the new Bookstore example here.
  • Support for extensible SQL strategies on the JDBC connector
  • CXF web service proxying now supports attachments
  • CXF clients now pass custom Mule message properties correctly to the server
  • Native JMS redelivery counters if supported by a JMS server (with fallback to the old-style manual counts)
  • Improved JMS topic subscriptions support for SunMQ/OpenMQ
  • Improved JNDI lookup of JMS destinations having slashes in their names
  • Explicit control over JMS temporary reply destinations creation on a connector/endpoint level
  • Every inbound aggregator router now supports timeout and failOnTimeout for partial aggregations
  • Every connector now has a validateConnections configuration attribute, acting as a performance optimization hint
  • Fixed failures with some IBM J9 and Oracle JRockit versions when proprietary JVM optimizations were enabled
  • Clarified and cleaned up message property scopes and precedence
  • Clean up of the use of OSGi rebundled dependencies
  • Many bug fixes and increased test coverage
<< Previous: Basic Usage Next: Mule Enterprise 2.2 Release Notes >>
Adaptavist Theme Builder Powered by Atlassian Confluence