Mule ESB 3.3.0 Release Notes

June 26, 2012

MuleSoft is pleased to announce the release of Mule ESB 3.3 which introduces powerful new functionality and improvements to our industry-leading ESB software.

These release notes apply to both the Community and the Enterprise editions of Mule ESB 3.3. Where appropriate, we have applied an Enterprise Edition marker to identify features or functionality that are available only in the Enterprise edition.

For this release, we have focused our efforts on expanding the features and capabilities of Mule ESB’s Studio graphical interface and on fixing known issues from the previous release. We have resolved hundreds of issues and hardened our product to ensure further stability and improve ease-of-use.

We highly recommend upgrading to Mule ESB 3.3 to take advantage of Anypoint DataMapper and unified Mule Expression language, our new iterative processor and our “in-memory” data caching.

Document Revision History

June 26, 2012, v1.0 Initial Publication

Current Release Version

Mule ESB 3.3.0
Enterprise Edition
Mule ESB 3.3.0
Community Edition


Version 3.3.0
Build 19919

Version 3.3.0
Build 24524


Build 201206220448

Build 201204251946


Build f56e9aa


SAP Enterprise

Version 1.2


CMIS Connector

Version 1.6

Version 1.6

Magento Connector

Version 1.5

Version 1.5

MongoDB Connector

Version 2.1

Version 2.1

Salesforce Connector

Version 4.3

Version 4.3

Twilio Connector

Version 1.2

Version 1.2

Twitter Connector

Version 2.6

Version 2.6

New Features and Functionality

We are excited to launch a new set of tools in Mule ESB 3.3 that have been designed to further increase the speed and efficiency of systems integration.

Mule ESB and Studio

  • Cache: Enterprise Edition Improves performance with “in memory” caching of messages, such as the results of service calls. Refer to Cache documentation for more details.

  • Anypoint DataMapper: Transforms data, using a graphical interface, from one format to another. This powerful, new feature can even map specific fields within the message structure and it supports the transformation to and from the following data formats: XML, JSON, CSV, POJOs, collections of POJOs, and EXCEL. Refer to DataMapper documentation for more details.
    + DataMapper is fully available only in Mule ESB Enterprise Edition. Enterprise Edition Experiment with DataMapper in Mule ESB Community Edition to evaluate this powerful new tool in Studio; download Mule ESB Enterprise to RUN an application and see DataMapper in action.

  • Improved error handling: Integrates new exception strategies into Studio. These include: Catch and Rollback exception strategies, and Choice exception strategy, which handles errors conditionally, according to the type of exception thrown. Refer to Error Handling documentation for more details.

  • Iterative processing using Foreach: Allows for iterative, loop-type processing of a message payload or properties while maintaining the original message context. Refer to Foreach documentation for more details.

  • Simplified expressions: Unifies an expression language to promote consistency and ease-of-use for message validation, filtering, routing, or transformation. Refer to Mule Expression Language MEL documentation for more details.

  • SAP Endpoint: Enterprise Edition
    Presents an efficient, new SAP Endpoint in Studio that facilitates seamless SAP integration, including SAP-to-SalesForce integration. Further, Mule can now send and receive messages in SAP iDocs format. Refer to the SAP Endpoint documentation to learn about the additional libraries required to enable the SAP Endpoint in Studio.

  • Business events: Enterprise Edition Enables the configuration and tracking of business events and key performance indicators in Studio. Refer to Business Events documentation for more details.

  • SCM support: Controls the evolution of a Studio project by supporting popular Software Configuration Management tools: Git and Subversion. Install SCM plugins to track and control changes in a Studio project. Refer to Git and Subversion documentation for more details.

  • Maven support: Enables import of projects built within the Maven framework into Studio, and export of Studio-built projects to Maven. Install Maven’s plugins to move projects back and forth between build tools. Refer to Importing and Exporting documentation for more details.

MuleSoft Management Console

Enterprise Edition

  • High availability support: Supports Active/Passive (that is, cold standby) configuration for the management system. Refer to Persisting Environment Data for more details.

  • Persistence alternatives: Officially supports Oracle and PostgreSQL database options for persisting management configuration, deployment and business event data. Refer to Persisting Transaction Data and Persisting Environment Data documentation for more details.

  • Audit log: Offers an Audit Log that enables searches for user login activity such as, adding server registration/de-registration. Refer to Audit Logs documentation for more details.

Noteworthy Improvements

What follows is a list of major improvements MuleSoft is proud to include and make available in 3.3 GA.

Mule ESB and Studio

  • Spring 3.1 upgrade: Includes support for Spring Bean definition profiles and updated namespaces: spring-beans-3.1 and spring-beans-current.

  • Apache CXF 2.5.1 upgrade: Supports the latest bug fixes and enhancements in the CXF Web Services framework.

  • WS-Security access: *Enterprise Edition* Enables WS-Security on a SOAP component in Studio to provide application-layer security for a Web service. Refer to Enabling WS-Security documentation for more details.

  • Message property improvements: Scopes, copies, and consistently stores session and invocation message properties.

  • Message and variable transformer addition: Simplifies the management of properties, variables and attachments; replaces the Message Property transformer, which is now deprecated. Refer to Transformers documentation for more details.

  • HTTP improvements: Extends the set of HTTP-specific message properties and makes their behavior more consistent. Further, adds specific components and transformers to facilitate the creation of HTTP response elements.

  • Mule application publication: Enables publication of Mule Studio applications to the repository in the Mule Management Console and/or Mule iON (now known as CloudHub).

  • New templates Includes several new project templates upon which to build a new Studio project. Refer to Anypoint Exchange for more details.

  • Java 7 support: Mule ESB 3.3 is certified and tested to support Java 7.

Mule Management Console

Enterprise Edition

  • Enhanced LDAP support: Facilitates implementation of LDAP-based authentication and authorization using new tools and templates. Refer to LDAP Authentication documentation for more details.

  • REST API server management: Provides REST APIs to access much of the console’s functionality, including server management. Refer to REST API documentation for more details.

  • Performance: Improves the console’s performance for threads, thread-pools, deployments, and applications.

Hardware and Software System Requirements

For most use cases, Mule ESB 3.3 does not change the hardware and software system requirements established by Mule ESB 3.2.

Contact MuleSoft with any questions you may have about system requirements.

Important Notes and Known Issues in this Release

This list covers some of the known issues with Mule ESB 3.3. Please read this list before reporting any issues you may have spotted.

Mule ESB

Issue Description


Exception Strategies are not being invoked in a flow with an Ajax inbound endpoint.
Workaround: Enclose flow logic in a flow invoked by VM.


Request-reply outbound endpoint sends reply to caller temp queue instead of self temp queue
Workaround: None


Referencing "exception" inside a groovy script should return null if there were no exception thrown
Workaround: Use exceptionPayload.


Null' is used both as a response from message processors with no result and to signify a message dropped by a filter
Workaround: None


Workaround: A patch has been applied to resolve the issue.


Do not always serialize Mule session security context
Workaround: None


Cannot override the JsonTransformerResolver
Workaround: None


Incorrect checking for supported transformer types in DefaultMuleMessage
Workaround: None


Cache stores intermediate payload of aggregators instead of final payload contents
Workaround: None


HTTP Polling on a cluster: all nodes poll independently
Workaround: Poll using Quartz.


When JMS messages are rolled back, response to reply-to is still sent
Workaround: Adding an invocation property will avoid reply to processing. You can use the following transformer after the failing endpoint:


Creating/disbanding clusters repeatedly in a short period of time causes them to shutdown
Workaround: Avoid recreating the cluster repeatedly.

Mule Studio

Issue Description


When you configure any of the JDBC datasources (MySQL, Oracle, etc.), the driver is not added.
Workaround: Add the driver manually by right-clicking on project root > Build Path > Add External Libraries > Browse; then add the corresponding . jar file.


Neither the HTTP nor HTTPS Polling Connectors can be referenced using the Properties pane in the Message Flow view.
Workaround: Make the reference using the XML configuration view by adding this: ref="HTTP_Polling".


When you remove a Request-Response endpoint or replace it with a one-way endpoint in the Message Flow view, the response element is not removed from the XML configuration file.
Workaround: Delete the Response element manually from the configuration file using the XML editor.


Unable to add a response element when creating a second flow within a single .mflow file.
Workaround: Add the response element manually in the XML configuration.

For request-response endpoints embedded in a composite source within a subflow, icons do not show the proper exchange pattern.
Workaround: This is only a matter of visual aesthetics within the graphical interface; if you set the correct exchange pattern through the Properties pane, the flow should work as intended, despite appearances on the Message Flow canvas.


The Description field is not persisted when you switch back and forth between the Message Flow and XML configuration views. This issue may appear in the bundled examples that are included in Mule Studio. Currently, there is no way to populate the Description field using the graphical interface.
Workaround: Once the application is complete and you are sure that you no longer need to use the Message Flow view, copy the description and insert it into the configuration file using the XML editor.

When you create a project from an existing template, the Problems pane may display errors such as the following:
"Unable to find type 'org.ordermgmt.OrdersView' on build path of project order_f”
Workaround: From the main menu, navigate to \{\{Project > Clean…​ }}, then select clean all projects. This re-compiles all your projects, so that these errors no longer appear.

When you install the Windows 64-bit version of Mule Studio with the IBM JDK, then create a project using the Order Discounter template, the Problems pane may display errors such as the following:
"Attribute key is not defined as a valid property of object Element:Objects is not allowed to be child of element Object"
Workaround: Ignore the errors and run your application. It will run successfully.


Response section in the Composite Source is not being reflected in the canvas.
Workaround: None


When using eGit and committing Mule projects, usually one or more of src/(main and test) or (java and resources) will be empty and therefore ignored by git.
Workaround: reload the workspace/restart Studio. Studio will generate the missing directories this way (and will show as untracked files).


Generate WSDL in the SOAP component works with CXF version 2.1.3, instead of using 2.5.1. This can cause the loss some part of the WSDL generation.
Workaround: None


There are backwards compatibility issues with the evaluator attribute when using expressions, as STUDIO supports only the latest version of the ESB, version 3.3. If you attempt to use the expression evaluator attribute, it will be marked as an error.
Workaround: use the new MEL (Mule Expressions Language) format adding the evaluator prefix before the expression.


DataMapper - Complex XMLs. Need the ability to handle nested and recurring elements in the XML.
Workaround: None


DataMapper - Need support for custom Java Functions.
Workaround: None


DataMapper - Need support for multiple input sources that maps to multiple output sources.
Workaround: None


DataMapper - Need ability to map for XML.Any elements.
Workaround: None

Mule Management Console

Enterprise Edition

Issue Description


Business Event Analyzer: only custom events are displayed on transaction details if HttpRequestToNameString is used.
Workaround: Change “Doc:name” to something different from the flow name.
<flow name="HelloWorld" doc:name="HelloWorld2" tracking:enable-default-events="true">.
Enable events on transformer elements as needed and, optionally, remove doc:name (in order to avoid overwriting the flow doc name):
<transformer ref="HttpRequestToNameString" tracking:enable-default-events="true"/>


Restarting one cluster restarts all the clusters that have been configured.
Workaround: None


A cluster can only be disbanded if all nodes are running.
Workaround: None


Flow information for clusters is the same for every cluster when they are all using the same application.
Workaround: To view the correct flow information, select each cluster individually through the left-hand menu panel.


When you create a cluster, not all the applications deployed to the server group get properly removed.
Workaround: Before creating a cluster, undeploy all applications from the cluster nodes, then remove the nodes from your server group.


Post Process Notifications for "one-way" endpoints are not being registered, which causes Business Events to be marked as failed.
Workaround: None


In the Business Events tracker, incorrectly reports the name of the flow associated with a given exception strategy. Specifically, when a message jumps from flow A to sub-flow B, then returns to Flow A, and a component throws an exception in Flow A, the Business Events list Flow A’s exception messages under Flow B’s name.
Workaround: None

Known Issues:

  1. If an input stream is used as a payload and combined with clustering, when the processing goes from one node to the other, in Mule 3.3.0 the stream truncates and in Mule 3.3.1 an exception is thrown.

  2. Sending JMS messages between Mule 3.3.1 and Mule 3.2.1 doesn’t work because the Mule session header encoding is incompatible between the two. Add a LegacySessionHandler to make this work.

Mule SAP Endpoint

Enterprise Edition

Non JCo Attributes are added to the destination configuration.
Workaround: None

Endpoint type has a default value in the schema file.
Workaround: None

Calling JCoServer.stop() signals the server to stop, but does not actually stop the server.
Workaround: None

Fixed in this Release

Mule ESB

View Resolved Issues

Issue Description


on-redelivery-attempts-exceeded does not support doc:name attribute


Session variable gets lost if using an enricher


Custom transformers are not registered on mule context


TransactionalQueueManager loads all keys from all ListableObjectStores in order to populate internal message queues


Unable to set content-type on RestServiceWrapper


Cannot use QueuePersistenceObjectStore on UntilSuccessful


Transport archetype creates test using deprecated methods


Attributes name for basic functionality is optional but should be required


Failed to initialize app. MBean Exception.


WS-Security element should not support Validators and Security Manager if the CXF MP is a client


Expression evaluators that can be used in filters only fail with obscure error messages if used in no valid places


expression-component does not allow variable declaration


Endpoint response message processors should not be processed when an endpoint doesn’t have a response


AbstractMessageReceiver returns value even when endpoint exchange pattern is one-way


Proxy Service fails with NPE when the WSDL has Faults defined


AttributeEvaluator does not support parentheses inside expressions


Filters in sub-flows do not filter as expect and should (rather only act as sub-flow 'return')


Missing implicit conversion for converters


DefaultInboundEndpoint flowConstruct has setter but no getter


Default mule application mule context is private


VM Queue not picking up messages previously persisted in the queuestore directly


Application Deployment Descriptor is not properly closed


Default Exception Strategy ignored with CXF component


XA transactions causing an increment in ActiveMQ consumers


When a Mule object (application, connector, flow, endpoint, etc.) is stopped more than once, the second and later stops have no effect


Application of a transformer chain to a mule message can produce different return types


activemq-xa connector does not reconnect to JMS provider once disconnected


Transactions on one-way vm queues causes CPU to go warm


spring.handlers and spring.schema are not generated correctly within the embedded distribution


Application fails to start when using until-successful router with a persistent ObjectStore


Commit on exception strategy JMS, FILE and FTP are transport are not consuming the message


CXF swallows exceptions in flows, prevents exception strategies from processing exceptions


As from 3.2 aggregators no longer maintain the order events are received when creating MuleMessageCollection


Inconsistent definition of some expression evaluators


ConcurrentModificationException during serialization of MuleSession with SessionHandler if there is a non-serializable property


Keystore type configuration is incorrect


Mule throws EOFException when it finds an empty message within a queue store


Reply-To doesn’t work for WMQ transport


ReplyTo property is lost because is not properly propagated between events


ActiveMQ web documentation should explain activemq jar inclusion in lib directory


File connector in 3.2.0 ignores #[header:originalFilename] and writes no file


JDBC DataStore requires that the JDBCConnector has the queryTimeout set to work


TransactionalQueueManager is only started after inbound endpoints/sources - Duplicate events can appear in SEDA queues


Javadoc no longer generated with Maven 3 build


Http transport doesn’t work for first invocation


http endpoint port attribute does not support expressions


Hazelcast cluster stops consuming messages after node restart


Failure to create implicitly chains of 2 or more Transformers


Mule should not use default user exposed object store for internal purposes.


Default app config in standalone distribution refers to 3.2 XML schema


Soak test fails after 15 to 25 minutes, with multiple resources locking on to ActiveMQ resource


Batch update forces Map payload when that is not needed


Configuring a Consumable Filter doc for Cache Message Processor is missing


muleContext.getClusterNodeId() is always 0


NPEs in logs while raising nodes


Polling + Updating JDBC database throws Connection Closed exceptions, always fails when using services


Application’s lifecycle is applied to global server’s objects


recover() method in TransactionalQueueManager should check for empty keySet from object store


Cannot reference JDBC Object Store using JDBC EE schema


Cannot reference JDBC Datasources using JDBC EE schema


spring.handlers and spring.schema are not generated correctly within the embedded distribution


Mule throws EOFException when it finds an empty message within a queue store


Mule fails to start on HP-UX


activemq-xa connector does not reconnect to JMS provider once disconnected

Mule Studio

View Resolved Issues

Issue Description


Request Reply (flow control) must have a way from the UI to add inbound and outbound endpoints


In the MuleMQ and ActiveMQ widget dialog box, in the MuleMQ properties tab, checking the "XA Support mode" causes the dialog box to go blank for a second


Spring import schema does not have doc:Name attribute


Transactions dialog for VM endpoint is too big


WMQ Endpoint: Exchange pattern should be placed after Display Name


Quartz: duplicated job attribute


HTTP Outbound endpoint: Remove the blank option from the HTTP method attribute


Unable to create a bean - Getting Null Pointer Exception when trying to create a bean in a JDBC connector


Installing a newer Studio version and using an old workspace (the default one) causes errors and the runtime is lost


Getting concurrent modification exception when adding CC and referencing them


Two-way editing issue: Salesforce and Twitter streaming endpoint are parsed as invalid configuration and removed from canvas and then XML


Reconnection Strategies: Add the 'Not use reconnection strategy' option


WMQ XA connector should be considered as a checkbox inside WMQ to be enabled and not a separate connector


Getting JNPE when deploying to iON (now known as CloudHub) not having selected a project

Mule Management Console

Enterprise Edition

View Resolved Issues

Issue Description


Server Metrics charts are slow to load even with a single mule instance


Deployment of new version of Application is not working as expected


Cannot start Mule 2.2.8 using 3.3/2.2.8 agent, -agent-mule2-impl-3.3.0-RC2-full.jar


UI becomes unresponsive when trying to save a cron job.


On Business Event, queries do not show new generated events while agent is on heavy load (if load is reduced situation goes back to normal).


takes too long to show Deployments (Tab, and portlet)


On Event Analyzer, Processing Time, using m as time unit is allowed, but system does not process it.


On Servers tab, if cluster item is clicked in the left side tree panel, the cluster view is not opened.

Third Party Connectors and other modules

At this time, not all of the third party modules you may have been using with previous versions of Mule ESB have been upgraded to work with Mule ESB 3.3. Contact MuleSoft if you have a question about a specific module.

Migrating from Mule ESB 3.2 to 3.3

The following sub-sections offer details on the changed and improved behaviors that Mule ESB 3.3 introduces. For more details on how to migrate from previous versions of Mule ESB, access the library of Migration Guides.

System Variables
Message Properties
Transformation Changes
Spring Framework Upgrade
Flow Behavior
Message Enricher
Error handling
Web Services
API Changes

Environment Variables

Neither MULE_HOME nor MULE_BASE is required or recommended to run Mule 3.3. If either of these variables exist on a system slated for Mule 3.3 installation, MuleSoft recommends that you remove them.

Message Properties

Mule ESB 3.3 resolves several issues involving message properties and includes two improvements. Refer to Transformers documentation for further details on Mule Studio’s new transformers.

  • Fixed: Mule does not lose invocation properties in a flow with request-response outbound endpoints. (Also fixed in Mule versions 3.1.4 and 3.2.2.)

  • Fixed: Mule correctly propagates invocation properties in flows with splitters and routers. (Also fixed in Mule versions 3.1.4 and 3.2.2.)

  • Fixed: Mule’s Collection Aggregator correctly aggregates invocation properties. (Also fixed in Mule versions 3.1.4 and 3.2.2.)

  • Fixed: The </request-reply> router correctly preserves session properties. (Also fixed in Mule versions 3.1.4 and 3.2.2.)

  • Fixed: Mule correctly propagates session properties in a flow with splitters and routers. (Also fixed in Mule versions 3.1.4 and 3.2.2.)

  • Improved: If Mule encounters a message with session properties which cannot be serialized — forcing it to write the message to a queue — Mule issues a warning, but does not throw an exception. This behavior is consistent with the warning Mule issues when an endpoint receives a message with a session property that cannot be serialized.

  • Improved: Mule uses a single map of invocation properties to split messages on each flow (excluding asynchronous). Further, when Mule sends messages down multiple routes for processing, all the routers share the same set of invocation properties.

Transformation Changes

Mule 3.3 introduces three new behaviors associated with the way messages are transformed from one data format to another (for example, from File to String):

Behavior Improved Behavior Old Behavior

enforced transformation

A transformer yields an expected type of message payload; the flow must be prepared to manage only one type of output.

A transformer yields one of several possible types of message payload; transformed payload type is unknown and the flow must be prepared to manage several different outputs.

implicit transformation

If a transformer exists to change message payloads from type B to C, and it receives a message payload type A, Mule implicitly looks for a converter that can convert the message payload from A to B, before introducing the message payload to the B-to-C transformer.

If a transformer receives an unexpected type of message payload, it throws an exception.

extended transformer lookup

If a transformer exists to change message payloads from type B to C, and it receives a message payload type A, Mule implicitly looks for a converter that can convert the message payload from A to B, before introducing the message payload to the B-to-C transformer. If Mule cannot find an A-to-B converter, it extends its search to look for combinations of converters that will yield a message payload type B. For example, it may convert a message payload from A to F, then use another converter to change it from F to B before introducing it to the B-to-C transformer.

If a transformer receives an unexpected type of message payload, and cannot find a single converter to match its conversion needs, it throws an exception.

If you do not wish to use these new transformer behaviors on your application — if the behaviors are not compatible with the way your application is configured, for example — you can disable the behaviors in Mule ESB 3.3 by adding the following code snippet to the Mule configuration of your application:

<configuration useExtendedTransformations="false"/>

Spring Framework Upgrade

A key piece of Mule’s configuration mechanism, Spring, has recently released a new version of its framework. Spring 3.1.0 – upgraded from 3.0.3 – fixes bugs and adds new features, which Mule ESB 3.3 supports. To read more about new features and fixes in Spring 3.1, refer to Spring’s reference documentation.


To take advantage of the new features and bug fixes in Spring 3.1, use one of the two new corresponding namespaces:

Use spring-beans-current to instruct your application to use the latest version of Spring that is available in Mule. When Spring releases new versions, you need not manually update the namespaces in your application.

Bean Definition Profiles

Mule’s configuration file takes advantage of Spring’s new ability to create bean definition profiles. You can use Spring bean definition profiles to register different beans for different target environments, instead of using one bean for all target environments. Refer to Spring’s blog posting for more information about bean definition profiles.

As an example, you can use bean definition profiles to create and use unique connectors for different profiles.

  1. Create bean profiles and configure them for separate profiles.

    <mule xmlns="" ...>
             <spring:beans profile="one">
                 <stdio:connector name="stdioConnector" messageDelayTime="10"  outputMessage="profile 1: " promptMessage="prompt message 1"/>
            <spring:beans profile="two">
                <stdio:connector name="stdioConnector" messageDelayTime="10"
    outputMessage="profile 2: " promptMessage="promtp message 2"/>
            <flow name="service">
                 <stdio:inbound-endpoint name="in" system="IN" connector-ref="stdioConnector"
    exchange-pattern="one-way" />
                 <stdio:outbound-endpoint name="out" system="OUT" connector-ref="stdioConnector"
    exchange-pattern="one-way" />
  2. When starting a Mule instance, use a JVM argument to set the profile system property to identify which bean profile Mule should use. Your setting applies to all applications deployed on the Mule instance.

Flow Behavior

Mule ESB 3.3 introduces changes designed to refine flow behavior. Although they offer much in the way of improvement and consistency, the changes only affect a small number of use cases. What follows is a summary of the changes, and information on how to ensure your Mule ESB 3.2 application continues to behave as expected in Mule ESB 3.3.


In Mule ESB 3.3, you can add a filter to a flow or a subflow and expect that it will behave dependably and consistently in both.

In previous 3.x versions of Mule ESB, the behavior of a filter differed depending on whether you added it to a flow or a subflow.

  • A filter in a flow dropped a failed message but did not discard the file (see Example 1, below)

  • A filter in a subflow dropped a failed message silently, discarded the file, and allowed the message to continue into the main flow for processing (see Example 2, below).

In Mule ESB 3.3, a filter’s behavior is consistent in all flows, subflows and child flows: it drops a failed message but does not discard the file. (See Example 3, below.) This makes it far easier to trace an error to its source and resolve any problem with the filter or a flow.

Example 1, file NOT discarded

<flow name="flowWithFilter>
  <http:inbound-endpoint address="http://localhost"/>
  <expression-filter expression="0 == 1">
  <file:outbound-endpoint path="/tmp" />

Example 2, file discarded

<flow name="flowWithFilter>
  <http:inbound-endpoint address="http://localhost"/>
  <flow-ref name="filteringSubFlow" />
  <file:outbound-endpoint path="/tmp" />

<sub-flow name="filteringSubFlow">
  <expression-filter expression="0 == 1">

Example 3, file NOT discarded

<flow name="flowWithFilter>
  <http:inbound-endpoint address="http://localhost"/>
  <flow-ref name="filteringSubFlow" />
  <file:outbound-endpoint path="/tmp" />

<sub-flow name="filteringSubFlow">
  <expression-filter expression="0 == 1">

Request-Response Inbound Endpoint with One-Way Outbound Endpoints.

In Mule ESB 3.3, you can add a one-way outbound endpoint to the middle or to the end of flow that begins with a request-response inbound endpoint and expect that it will behave dependably and consistently in both places.

In previous 3.x versions of Mule ESB, the behavior of a one-way outbound endpoint differed depending on where you placed it in a flow. In Mule ESB 3.3, the behavior of a one-way outbound endpoint has been made consistent so that it will never return a null value to the caller.

In Mule ESB 3.3, a flow such as the one illustrated in Example 1, below, sends a request message response rather than null response to the caller. This “never null” behavior remains unchanged in flows, such as Example 2, which contain a one-way outbound endpoint in the middle of a flow. Regardless of where you place it in a flow that begins with a request-response inbound endpoint, a one-way outbound endpoint will never return a response of null in Mule ESB 3.3.

Example 1

<flow name="flowWithFilter>
  <http:inbound-endpoint address="http://localhost" exchange-pattern="request-response/>
  <file:outbound-endpoint path="/tmp" exchange-pattern="one-way"/>

Example 2

<flow name="flowWithFilter>
  <http:inbound-endpoint address="http://localhost" exchange-pattern="request-response/>
  <file:outbound-endpoint path="/tmp" exchange-pattern="one-way"/>
  <file:outbound-endpoint path="/other" exchange-pattern="one-way"/>

If you do not wish to enforce this endpoint behavior in your application — if the behavior is not compatible with the way your application is configured, for example — you can disable the behavior in Mule ESB 3.3 by adding the following code snippet to the Mule configuration of your application:

<configuration flowEndingWithOneWayEndpointReturnsNull="true" />

Alternatively, you can modify your application to prevent Mule ESB 3.3 from applying this new endpoint behavior. You can complete the modification in one of two ways:

  1. Change the exchange pattern of the inbound endpoint in your flow from request-response to one-way. This ensures that Mule does not return a response to the caller. (Exception: a one-way inbound HTTP endpoint returns an empty response to the caller with status code “OK”.)

  2. Insert a transformer into your flow to explicitly define the message’s response payload type. Insert the transformer in one of two places in your flow:

    • immediately after the one-way outbound endpoint

    • inside the response block (in the Mule XML config) of the inbound endpoint

Message Enricher

Mule ESB 3.3 has corrected the behavior of the Message Enricher so that it does not propagate session variable changes to the main flow. Mule now isolates the Message Enricher’s processing flow from the main flow in which it resides. In other words, any changes that Mule makes to a message’s session variables while it is within the scope of a Message Enricher are not carried with the message when it re-enters the main flow.

If you do not wish to enforce this new Message Enricher behavior on your application — if the behavior is not compatible with the way your application is configured, for example — you can disable the behavior in Mule ESB 3.3 by adding the following code snippet to your application:

<configuration enricherPropagatesSessionVariableChanges="true" />

Alternatively, you can modify your application to prevent Mule ESB 3.3 from applying this new Message Enricher behavior. To ensure that all changes a Message Enricher makes to session variables are propagated to the main flow, add one child <enrich> element to each session variable that the Message Enricher touches (i.e. adds or modifies). Refer to the following example of such a modification.

    <flow-ref name="otherFlow"/>
    <enrich source="#[sessionVars['newSessionVar']]" target="#[sessionVars['newSessionVar']]" />
    <enrich source="#[sessionVars['modifiedSessionVar']]" target="#[sessionVars['modifiedSessionVar']]" />

Error handling

Mule ESB 3.3 offers improvements to error handling through the use of exception strategies. When a message being processed through a Mule flow throws an exception, normal flow execution stops and processes transfers to the message processor sequence within the exception strategy. You can incorporate any number of message processors – and in one case, other exception strategies – into an exception strategy to handle exceptions precisely as you wish.

Further, Mule ESB 3.3 improves the way private flows handle errors. In Mule ESB 3.x, if a private flow encounters an error and throws an exception, it invokes its own exception strategy, produces an exception strategy result message of NullPayload, and allows Mule to continue processing the message in the parent flow.

In Mule ESB 3.3, the parent flow’s exception strategy — default, catch, rollback, choice or ref — handles all exceptions thrown within a private flow.

If you do not wish to enforce this new error handling behavior for private flows on your application — if the behavior is not compatible with the way your private flow is configured, for example — you can disable the behavior in Mule ESB 3.3 by wrapping the private flow with another private flow in which you have configured a catch exception strategy.

<flow name="parentFlow">
   <flow-ref name="privateFlowProxy"/>

<flow name="privateFlowProxy">
   <flow-ref name="privateFlow"/>

<flow name="privateFlow">
   <test:component throwException="true"/>

Refer to Error Handling documentation to learn more about Mule ESB 3.3’s exception strategies.

Web Services

The following subsections outline changes and improvements Mule ESB 3.3 applies to applications that involve Web services.

CXF Version Upgrade

Mule ESB leverages Apache’s CXF framework for building and configuring Web services. Recently, Apache has upgraded CXF to version 2.5.1 which fixes numerous bugs and provides greater stability. Apache has also upgraded their WSS4J product (a security standards implementation for Web services) from 1.5.8 to 1.6.1. Mule ESB 3.3 supports the latest versions of both CXF and WSS4J.

Refer to the CXF 2.4, CXF 2.5, and WSS4J 1.6 migration guides to learn about improvements Apache has made to their Web services framework.

Error Handling in CXF

Mule ESB 3.3 offers the following improvements to the way it handles errors that occur in flows that involve CXF Web services.

  1. When a message throws an exception in a flow with a CXF Web service, Mule invokes the exception strategy you have defined for that flow. Depending upon the type of exception strategy you have defined, and whether the CXF Web service is publishing, consuming or proxying information, Mule either:

    • Returns a SOAP Fault message to the caller

    • Propagates the original cause of the error in the flow

  2. When Mule returns a SOAP fault to a caller, it sets the HTTP status code to 500 “Internal Server Error”.

  3. CXF propagates the correct exception whenever an exception occurs.

  4. Mule ESB3.3 has removed the onException attribute from the CXF inbound message processors. (Previously, Mule ESB 3.x used onException as a workaround in order to be able to return a SOAP fault to a caller or invoke and exception strategy.)

Refer to CXF Error Handling for more detailed information regarding Web services and error handling.


Enterprise Edition

In Mule ESB 3.3, you can implement application-layer security by enabling WS-security (a CXF configuration) on your Web service. WS-security defines a new SOAP header which is capable of carrying various security tokens that systems use to identify a Web service caller’s identity and privileges. Refer to the Enabling WS-Security for detailed instructions on how to enable it on your Web service.

Working in Studio, you can add key-value pairs to a SOAP component in order to create a map of key-value pairs that correspond to the CXF WSS4J security-configuration text strings in WSHandlerConstants and WSConstants. In XML, you add a key-value pair inside the ws-config child element of a ws-security element.

Further, you can add custom Token Validators to authenticate the message credentials your Web service transmits or receives. You can customize a token validator by referencing an existing bean which applies, replaces, or extends the default behavior associated with a specific security token.

        <cxf:property key="action" value="UsernameToken"/>
        <cxf:username-token-validator ref="validatorRef"/>

Mule Security Manager

Because the newest version of Apache’s WSS4J has changed the way it processes UserNameTokens — and because Mule supports the newest version of WSS4J — Mule ESB 3.3 introduces a new way to configure the Mule Security Manager to integrate with CXF.

To configure the Mule Security Manager in CXF in Mule ESB 3.2, you add the security manager callback as a password callback in the WSS4J map configuration, and CXF injects WSS4J configuration into the WSS4J interceptor. However, in the latest version of WSS4J, the callback handlers no longer perform validation activities; instead, they merely set the password on the callback. In other words, the authentication and validation tasks have been stripped from the WSS4J processors and transferred to token validators. This WSS4J change precipitated the modified way in which Mule ESB 3.3 configures the Mule Security Manager to work with CXF.

Mule ESB 3.2 Mule Security Manager Integration

<spring:bean name="wss4jInConfiguration"
    <spring:property name="sourceMap">
            <spring:entry key="action" value="UsernameToken" />
            <spring:entry key="passwordCallbackRef">
                <cxf:security-manager-callback id="serverCallback"/>

Mule ESB 3.3’s new method of configuring the Mule Security Manager may, therefore, be incompatible with your existing Mule ESB 3.x applications. To ensure that your Mule ESB 3.x application functions properly in Mule ESB 3.3, add a <cxf:mule-security-manager> child element within the <cxf:ws-security> element of your Web service flow.

Mule ESB 3.3 Mule Security Manager Integration

            <cxf:property key="action" value="UsernameToken" />

JiBX Databinding

Within the context of the CXF framework, data binding is the action of mapping data from XML documents to Java objects. In addition to aegis, jaxb and custom databinding, Mule ESB 3.3 introduces the ability to apply JiBX databinding to your Web service.

API Changes

View the changes introduced by the Mule ESB 3.3 API
Affected Change After Migrating to 3.3 Handler



org.mule.api.MuleSession.setProperty(String, Object)


Use org.mule.api.MuleSession.setProperty(String, Serializable)



Use org.mule.api.MuleSession.getProperty(String)



Use org.mule.api.MuleSession.removeProperty(String)



Use the default expression evaluators. Consult the expressions configuration reference for more information.



Mule ESB 3.3 introduced improved error handling, therefore, the CXF custom exception strategy no longer adds value.

org.mule.module.cxf.component.WebServiceWrapper Component


Mule ESB 3.3 enables you to send the result of a web service call to another endpoint using a flow.

Changes to org.mule.session.DefaultMuleSession/org.mule.DefaultMuleEvent Constructors in Mule ESB 3.3

Affected Change Migration



Use DefaultMuleSession() instead

DefaultMuleSession(FlowConstruct, MuleContext)


Use DefaultMuleSession() instead

DefaultMuleSession(MuleSession, MuleContext)


Use DefaultMuleSession(MuleSession session)

DefaultMuleSession(MuleSession, FlowConstruct)


Use DefaultMuleSession(MuleSession session)

DefaultMuleSession(MuleMessage, SessionHandler, FlowConstruct, MuleContext)



DefaultMuleSession(MuleMessage, SessionHandler, MuleContext)



DefaultMuleEvent constructors replaced by FlowConstruct parameters in Mule ESB 3.3

  • DefaultMuleEvent(MuleMessage message, MessageExchangePattern exchangePattern, MuleSession session)

  • DefaultMuleEvent(MuleMessage message, MessageExchangePattern exchangePattern, MuleSession session, ResponseOutputStream outputStream)

  • DefaultMuleEvent(MuleMessage message, MessageExchangePattern exchangePattern, MuleSession session, int timeout, Credentials credentials, ResponseOutputStream outputStream)

  • DefaultMuleEvent(MuleMessage message, URI messageSourceURI, MessageExchangePattern exchangePattern, MuleSession session)

  • DefaultMuleEvent(MuleMessage message, URI messageSourceURI, MessageExchangePattern exchangePattern, MuleSession session, ResponseOutputStream outputStream)

  • DefaultMuleEvent(MuleMessage message, URI messageSourceURI, MessageExchangePattern exchangePattern, MuleSession session, int timeout, Credentials credentials, ResponseOutputStream outputStream)

  • DefaultMuleEvent(MuleMessage message, InboundEndpoint endpoint, MuleSession session)

  • DefaultMuleEvent(MuleMessage message, InboundEndpoint endpoint, MuleSession session, ReplyToHandler replyToHandler, ResponseOutputStream outputStream)

  • DefaultMuleEvent(MuleMessage message, URI messageSourceURI, String messageSourceName, MessageExchangePattern exchangePattern, MuleSession session, int timeout, Credentials credentials, ResponseOutputStream outputStream, String encoding, boolean transacted, boolean synchronous, Object replyToDestination, ReplyToHandler replyToHandler)

Support Resources

Please refer to the following resources for assistance using Mule ESB 3.3.


Refer to MuleSoft’s online documentation at MuleSoft Docs for instructions on how to use the new features and improved functionality in Mule ESB 3.3.

Getting Help

Access MuleSoft’s Forum to pose questions and get help from Mule’s broad community of users.

Enterprise Edition To access MuleSoft’s expert support team, subscribe to Mule ESB Enterprise Edition and log in to MuleSoft’s Customer Portal.

Was this article helpful?

💙 Thanks for your feedback!

Give us your feedback!
We want to build the best documentation experience for you!
Help us improve with your feedback.
Take the survey!