Mule ESB 3.7.1 Release Notes

MuleSoft is pleased to announce the release of the Mule Runtime Engine 3.7.1, an Enterprise Only maintenance release. This release contains important fixes in DataWeave and also includes more than 20 bug fixes.

For MMC 3.7.1 release notes, see MMC 3.7.1 Release Notes.

Compatibility Information

Software Version

ESB Runtime


Anypoint™ Studio

June 2015 Update Site 1



Anypoint DevKit



1.5.1 and later

Hardware and Software Recommendations

Mule 3.7 was validated on the following; however earlier OS versions can work:

  • Java: JRE 1.7.0 (Recommended JRE 1.7.0_79/80), JRE 1.8

    Note: Mule 3.7 permits a JRE, whereas Anypoint Studio requires a JDK

  • OS: MacOS 10.10.3, HP-UX 11i V3, AIX 7.1, Windows 2012 R2 Server, Windows 8.1, Solaris 11.2, RHEL 7.0, Ubuntu Server 15.04

  • Hardware:

    • 2 GHz, dual-core CPU, or 2 virtual CPUs in virtualized environment

    • 2 GB RAM

    • 4 GB of storage

    • App Servers: Tomcat 7, Tomcat 8, Weblogic 12c, Enterprise 6.1, Community 8, Websphere 8, Jetty 8, Jetty 9

    • Databases: Oracle 11g, MySQL 5.5 +, DB2 10, PostgreSQL 9, Derby 10, Microsoft SQL Server 2014

Hardware and Software System Requirements

MuleSoft recommends a minimum of 4 GB RAM on a developer workstation. As applications become complex, consider adding more RAM. You can contact MuleSoft with any questions you may have about system requirements.

Bundled Runtime Manager Agent

This version of Mule ESB comes bundled with the Runtime Manager Agent Plugin version 1.1.0.

Enterprise Edition Fixed Issues

Issue Description


CXF does not set the correct mimeType


Message mime type/encoding must be reset when payload is set without a datatype


Hostname verification not working correctly with HTTPS proxy


Email transport fails to read new emails if inbox has 7 or more read emails in it


Synchronous until successful should retry on the original message


Loggers memory leak after fixing MULE-8635


UnsupportedOperationException when HTTP client closes connection before expected when using NB proessingStrategy


Broken link in


Missing NamespaceHandler entry for non-blocking-processing-strategy


Operation state handling in extensions api


Classloader leak using Oracle JDBC Driver


HTTP Requestor should not use Host property.


HTTP requestor should ignore 'Transfer-Encoding' property as it is a hop-by-hop header


HTTP listener should ignore 'Transfer-Encoding' property as it is a hop-by-hop header


Connection and Keep-Alive message properties should not affect Listener/Requestor connection reuse behavior.


Succesful undeployment is not show in console


Consider renaming @ImplementationOf to @ExtensionOf


It should not be mandatory for a class annotated with @Operation to depend on the config object


HTTp delete body is not allowed


Requests randomly fail (1 in 1M) with NPE, even at low conconcurrencies e.g. 50


Throttling delay causes requests to hang


Request-Response flow does not respond when non-blocking HTTP request is used within cache scope.


Cloudhub 3.6.0 / 3.6.1 AMI does not allow setting of Debug Logging


Hazelcast locks are not being destroyed


bti:xa-caching-connection-factory doesn’t use credentials to authenticate JMS sessions

Enterprise Known Issues

Issue Description


Boundary not sent on multipart responses


Multipart Content-Type header is sent twice when copying attachments


New HTTP Listener not working with some kind of attachments


Cannot set an array element in a property from an enricher.


WSC with basic auth wraps "error"s HTTP status code by throwing exceptions with timeouts


Slow xpath transformations due high usage of the class-loader.


Flow does not continue processing after enricher when using non blocking processing strategy.


Mule registry failing to lookup sub-flows


Contention accessing to transformers.


Deadlock found when getting operation execution.


DISCARD or DISCARD_OLDEST policies not working as expected when used in the Threading Profile of HTTP Listeners


Exception thrown in Mule Shutdown Hook


Logger categories are not working properly


Incorrect XSD generated for extension built using extension API


Class org.mule.routing.EventGroup has a static field (hasNoCommonRootId) that may cause aggregation to fail


MuleContext’s ExpressionLanguage is not properly initilized


Using Preemptive basic authentication in the new HTTP Module uses two request where the User/Pass are invalid


Loading classes is slower in 3.7 possible due the new weave-plugin.


Request-reply throws unexpected errors


Set attachment component not handling DataWeave transformer output correctly

MMC 3.7.1 Release Notes

The MMC 3.7.1 release primarily included bug fixes and improvements to performance. See the list of fixed JIRAs below:

Table 1. Fixed Items
Issue Description


Make maxExecutionTime warning configurable


Delete old deployment version after creating a new one


Do not attempt to fetch applications from server that is down


Improve performance discovering artifacts


Ensure undeployments succeed before deleting the deployment


Better handle of orphaned links

Migration Guide

No actions must be carried out to migrate from 3.7.0.

DataMapper Plugin

As of 3.7.0 DataMapper is now an optional plugin that must be installed inside the Mule runtime for applications that are using it.

To migrate DataMapper applications, install the DataMapper plugin manually following these steps:

  1. Download the DataMapper plugin from the "Customer Portal"

  2. Add the DataMapper plugin to the "plugins" folder in your <MULE_HOME> directory

Other Changes in Mule 3.7.1

Issue Description


mule-transport-axis was removed from standalone and embedded EE distributions. Following libraries were also removed as they are not required anymore: axis-1.4.jar, commons-discovery-0.4.jar and geronimo-jaxrpc_1.1_spec-1.1.jar


Mule ESB 3.7.0 requires version of Anypoint Enterprise Security to be 1.5.0 or greater


The wrapper.conf file now contains default garbage collection and memory settings configured to improve performance in an environment with 2 GB+ memory. If you need to run Mule with less than 2 GB of RAM, edit the wrapper.conf file.

Annotations and Registry Changes

Annotations are now the recommended way of getting hold of dependencies. Manual lookups through the Mule context registry are still supported but not recommended.

Initialization is now applied on dependency order, meaning that if object 'A' depends on 'B' and 'C', Mule guarantees that by the time that 'A' is initialised, 'B' and 'C' have already been initialised. Note that for this to work, to dependency has to be explicitly expresses through the javax.inject.Inject annotation or through a Spring configuration.

TransientRegistry is deprecated and no longer used by the runtime. SpringRegistry is now the only registry the runtime uses by default. AbstractMuleContextTestCase uses the new SimpleRegistry instead. addRegistry() and removeRegistry() methods from the MuleContext have been deprecated. Manually added registries cannot participate in dependency injection.

The org.mule.api.registry.Registry.registerObject(key, Object, metadata) method has been deprecated. The metadata is no longer used.

RegistryBroker and RegistryBrokerLifecycleManager classes have been deprecated. SimpleRegistryBootstrap is deprecated and is no longer used by the runtime. SpringRegistryBootstrap is used instead.

PreInjectProcessor, InjectProcessor, ObjectProcessor and all their implementation have been deprecated and are no longer used by the runtime. Use a Spring BeanPostProcessor instead.

Spring Changes

Spring’s init-method and destroy-method are no longer recommended when defining Spring beans that implement any of the Mule Lifecycle interfaces (Initialisable, Startable, Stoppable, Disposable)

Class org.mule.config.bootstrap.SimpleRegistryBootstrap.ArtifactType was moved to org.mule.config.bootstrap.ArtifactType

Spring Bean Definition parsers no longer automatically call the initialise() and dispose() methods. If you want to maintain that behavior in your custom parsers, you must explicitly do it yourself. An example of doing that would be:

private void setInitAndDisposeMethods(BeanDefintionBuilder builder, Class<?> parsedObjectType) {

   if (Initialisable.class.isAssignableFrom(parsedObjectType)) {

   if (Disposable.class.isAssignableFrom(parsedObjectType)) {

For further technical details, you can read the full spec at Mule-3.7.0-M1%5D-Registry-Consolidation,-Lifecycle-fix,-and-Dependency-Injection

Mule Migration Changes

Issue Description


TLS configuration is not mapped anymore to the default JVM system properties. In order to keep this behavior, define the following system property: mule.tls.disableSystemPropertiesMapping=false


Property http.relative.path was added to the inbound properties of the HTTP listener. This property reflects the value of the http.request.path property without the basePath part of the corresponding listener.


Lifecycle has been fixed. Considerations:

Initializable objects invoke only after the registry has instantiated all objects and successfully injected dependencies into them. initialise() is no longer eagerly invoked.


See Annotations section above.


In previous versions of Mule, domain home folders where created relative to current working directory instead of relative to <MULE_HOME> folder.

Now that this is fixed, if your Mule instance was started from a folder other than <MULE_HOME> then folder <WORKING_DIRECTORY>/.mule/<DOMAIN_NAME> must be moved to <MULE_HOME>/.mule/<DOMAIN_NAME>


The set-payload element is now implemented using a plain MessageProcessor instead of using a MessageTransformer. This means that <set-payload> continues working as before unless it is used as a transformer. (For example, inside an endpoint.)

To use SetPayloadTransformer in the Mule configuration file as a transformer, define it as a <custom-transformer> like this:

<custom-transformer class="org.mule.transformer.simple.SetPayloadTransformer">
    <spring:property name="value" value="someValue"/>


Applying a message transformer does not changes message’s data type if the payload was not replaced during the transformation.

In particular, this changes affects usages of message properties transformer configured like this:

<message-properties-transformer name="setResponseType" mimeType="text/baz" encoding="UTF-16BE"/>

That now must be configure in this way:

<message-properties-transformer name="setResponseType">
<add-message-property key="Content-Type" value="text/baz;charset=UTF-16BE"/>

Or like this:

<set-property propertyName="Content-Type" value="text/baz;charset=UTF-16BE"/>


Applying a message transformer that changes message’s payload updates the message data type, but instead of using transformer’s output data type, it uses a merge between payload’s and transformer data types.

If a transformer’s output data type does not provide a MIME type and/or encoding, then the original payload data type MIME type and/or encoding is used. This can cause different transformers to be applied to an application after the upgrade. In case there is a failure, use <set-payload> to set encoding and the MIME type while maintaining the same payload.


A new API for object serialization has been added through the ObjectSerializer interface. Use the following considerations:

If you were manually using the org.mule.util.SerializationUtils class in custom components, scripts or flows, you should use this API instead.

In the same way, where you were before catching a org.apache.commons.lang.SerializationException you should now expect a org.mule.api.serialization.SerializationException

You can now specify which is the default implementation of ObjectSerializer that you want your application to use. Such instances are used by Mule (although you’re free to use others in your custom code). By default, the ObjectSerializer implementation uses default Java serialization an behaves exactly the same as in prior versions.

To configure your custom serializer as the default you can use the <configuration> tag:

<configuration defaultObjectSerializer-ref="myCustomSerializer" />

There are many ways to obtain an ObjectSerializer. Recommended approachis through dependency injection. The following shows how to get the ObjectSerializer that has been configured as the default:

public class MyClass {

private ObjectSerializer objectSerializer;


Instead, if you want a specific named serializer (whether it’s the default or not) you can also do it like this:

public class MyClass {

private ObjectSerializer objectSerializer;


Finally, you can always pull it from the muleContext but dependency injection is preferred:


 // returns a named object serializer


Setting a message property/variable with the message’s payload when it is NullPayload removes the given property/variable instead of storing NullPayload.


MULE_ENCODING and Content-Type properties are not added on the outbound scope when message encoding or mimeType are updated. This was done in order to maintain consistency on MuleMessage data type and properties. In case any of these properties is needed, use <set-property> indicating the expected value.


Default maximum permanent generation has been increased to 256 mb. This property is only used when using Java 7. When using Java 8 the property may lead to a warning. In such case it can be comment out in the wrapper.conf file.


For those with custom implementation of class org.mule.config.spring.SpringXmlConfigurationBuilder, some important changes have been made:

The method createApplicationContext(MuleContext, ConfigResource[]) is now private. If you want to overwrite it, use doCreateApplicationContext(MuleContext, ConfigResource[], OptionalObjectsController) instead. If you want to intercept and change the list of resources to be loaded, override the new addResources(List<ConfigResource>) method


jasper-jdt-6.0.29 is not included anymore on Mule distributions because of detected vulnerabilities. In case this artifact is needed, when using Drools for example, manually add it to <MULE_HOME>/lib/opt


The wrapper.conf file now contains default garbage collection and memory settings configured to improve performance in an environment with 2 GB+ memory. If you need to run Mule with less memory, edit this file.


The HTTP connector now ignores its own custom properties (http.* ones) when sending a request and when responding to one, instead of transforming them to headers.

This means that:

  • Properties generated by a listener won’t affect a subsequent request

  • Properties generated by that request won’t affect the listener response If such properties are desired, they should be explicitly added as headers using a response/request builder


AbstractMessageReceiver.routeMessage(..) no longer return nulls if the endpoint exchange pattern is one-way. It always returns the result of the flow so if a transaction commit fails the exception strategy is executed using the message result of the flow execution. Custom message receivers implementations may need to be updated.

For a full and detailed list of considerations when migrating from the previous version to this one, see the MIGRATION.txt file, located in the root folder of Mule ESB.

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!