Contact Us 1-800-596-4880
  1. Homepage
  2. Archived Release Notes

  3. Mule ESB 3.7.1 Release Notes

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

3.7.1

Anypoint™ Studio

June 2015 Update Site 1

MMC

3.7.0

Anypoint DevKit

3.7.0

APIkit

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.

See Runtime Manager Agent Release Notes.

Enterprise Edition Fixed Issues

Issue Description

MULE-8804

CXF does not set the correct mimeType

MULE-8798

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

MULE-8779

Hostname verification not working correctly with HTTPS proxy

MULE-8776

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

MULE-8771

Synchronous until successful should retry on the original message

MULE-8769

Loggers memory leak after fixing MULE-8635

MULE-8755

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

MULE-8754

Broken link in BUILD.md

MULE-8751

Missing NamespaceHandler entry for non-blocking-processing-strategy

MULE-8724

Operation state handling in extensions api

MULE-8707

Classloader leak using Oracle JDBC Driver

MULE-8678

HTTP Requestor should not use Host property.

MULE-8677

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

MULE-8676

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

MULE-8626

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

MULE-8484

Succesful undeployment is not show in console

MULE-8480

Consider renaming @ImplementationOf to @ExtensionOf

MULE-8478

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

MULE-8328

HTTp delete body is not allowed

MULE-8163

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

EE-4563

Throttling delay causes requests to hang

EE-4541

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

EE-4539

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

EE-4529

Hazelcast locks are not being destroyed

EE-4498

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

Enterprise Known Issues

Issue Description

MULE-8814

Boundary not sent on multipart responses

MULE-8813

Multipart Content-Type header is sent twice when copying attachments

MULE-8806

New HTTP Listener not working with some kind of attachments

MULE-8787

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

MULE-8786

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

MULE-8780

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

MULE-8761

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

MULE-8743

Mule registry failing to lookup sub-flows

MULE-8720

Contention accessing to transformers.

MULE-8719

Deadlock found when getting operation execution.

MULE-8714

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

MULE-8704

Exception thrown in Mule Shutdown Hook

MULE-8703

Logger categories are not working properly

MULE-8700

Incorrect XSD generated for extension built using extension API

MULE-8697

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

MULE-8652

MuleContext’s ExpressionLanguage is not properly initilized

MULE-8605

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

EE-4545

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

EE-4544

Request-reply throws unexpected errors

EE-4528

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

MMC-1822

Make maxExecutionTime warning configurable

MMC-1823

Delete old deployment version after creating a new one

MMC-1824

Do not attempt to fetch applications from server that is down

MMC-1825

Improve performance discovering artifacts

MMC-1826

Ensure undeployments succeed before deleting the deployment

MMC-1827

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

EE-4333

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

SEC-240

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

EE-4441

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)) {
      builder.setInitMethodName(Initialisable.PHASE_NAME);
   }

   if (Disposable.class.isAssignableFrom(parsedObjectType)) {
       builder.setDestroyMethodName(Disposable.PHASE_NAME);
   }
}

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

MULE-8340

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

MULE-8367

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.

MULE-7588

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.

JSR-330

See Annotations section above.

MULE-8430

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>

MULE-8457

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"/>
</custom-transformer>

MULE-8469

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"/>
</message-properties-transformer>

Or like this:

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

MULE-8498

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.

MULE-7990

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 {

@Inject
@DefaultObjectSerializer
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 {

@Inject
@Named("mySerializer")
private ObjectSerializer objectSerializer;

}

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

 muleContext.getObjectSerializer();

 // returns a named object serializer
 muleContext.getRegistry().get("mySerializer")

MULE-8510

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

MULE-8483

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.

MULE-8592

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.

MULE-8569

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

MULE-8645

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

MULE-8641

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.

MULE-8628

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

MULE-8660

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.

See Also