MIGRATION GUIDE
===============

The following is a list of changes you have to execute to migrate from Mule Runtime Community edition version 3.4.x to version 3.7.x
Please check https://developer.mulesoft.com/docs/display/current/Mule+ESB for more details.

Migration changes from 3.8.x to 3.9.x
MULE-12245: Old Xalan and Xerces implementations were removed in favor of the newer versions included in Java. Only minor incompatibilities could result such as ordering changes of some XML attributes.
MULE-12017: log4j was updated from 2.5 to 2.8.2 and slf4j from 1.7.7 to 1.7.24. There is a minor incompatibility with code using logger.error(null, "message", e), in which case the first null argument should be omitted.
MULE-11948: Saxon was upgraded from 9.6.0-7 to 9.6.0-10
MULE-10720: xml-to-dom-transformer now transforms to org.w3c.dom.Document instead of byte[] by default.
MULE-9931: Transaction log files size are now restricted by size, using a default size of 500 mb. The configured size is just an approximated value which may be exceeded based on the size of the record store by the transaction. This is configurable using the attribute queueTransactionFilesSize of the <configuration> element.
    The size restriction applies to the set of transaction log files for local transactions and XA transactions independently meaning that if both types of transactions are used for queue the set of tx files will use up to 1 gb.
MULE-10100: Processing after a synchronous until successful resulting in a VoidMuleEvent will now continue with the original event.
MULE-10306: XML entity expansion in XML transformers is now disabled by default because it allows DoS attacks. To restore previous behaviour use the expandInternalEntities="true" attribute.
MULE-10686: XML entity expansion in Jersey is now disabled by default because it allows DoS attacks. To restore previous behaviour use the mule.xml.expandInternalEntities=true property.
MULE-10979: The default response timeout and default transaction timeout can't be configured using system properties on the command line or in the wrapper.conf file anymore. In replacement, use the configuration element. For example: <configuration defaultResponseTimeout="20000"  defaultTransactionTimeout="40000"/>.
MULE-11118: The HTTP listener now replies with status code 503 when the thread pool is exhausted (and poolExhaustedAction="ABORT") instead of closing the socket.
MULE-11825: In a DB template query, to set a DB param with the null value, you can use the "NULL" literal value. For example: <db:in-param name="name" defaultValue="NULL"/>
MULE-12385: Reconnection Strategies can only be defined in connector components or globally (using <configuration> element). In mule 3.x, defining reconnection strategies was being supported by the XSD, but ignored by Runtime. Now, the XSD was changed to not allow to use this invalid configuration.
MULE-12612: As FTP reconnection is at operation level, FTP connector does not support asynchronous reconnection strategies because it only makes sense if reconnection takes place during the start phase of the connector lifecycle. In case you use this kind of reconnection, please change them as follows: <reconnect blocking="true"/> inside FTP Connector, or just remove the blocking attribute.
MULE-13164: Inconsistent null return from one-way VM inbound endpoint. From Mule 3.9 one-way inbound VM endpoints will now consistently return null to Flow using a request-response outbound endpoint or Mule Client using send(). (In previous versions a successful response led to null return yet an error resulted in a message being returned.)
MULE-11246: The secretAliasId parameter isn't mandatory anymore. If not given, Mule will take the secretAliasId from the message to decrypt. Additionally, from 3.9.x the secretAliasId must be an hexadecimal value.
MULE-11161: The default PGP Encryption algorithm has been changed from CAST5 to AES 256.

Migration changes from 3.7.x to 3.8.x
MULE-9368: System property mule.sftp.knownHostsFile is now removed. Instead, the file with the known hosts must now be provided through the mule xml config file, in the knownHostsFile attribute of the connector or the endpoints.
MULE-9149: mule-module-jbpm was removed from standalone and embedded CE distributions. Following libraries were also removed as they are not required anymore: hibernate-commons-annotations-3.2.0.Final.jar, hibernate-core-3.6.0.Final.jar, hibernate-jpa-2.0-api-1.0.0.Final.jar, jbpm-api-4.4.jar, jbpm-jpdl-4.4.jar, jbpm-log-4.4.jar, jbpm-pvm-4.4.jar, juel-engine-2.1.0.jar, juel-impl-2.2.1.jar, livetribe-jsr223-2.0.5.jar
MULE-9337: TLSv1 is no longer listed as an enabled protocol, by default only TLSv1.1 and TLSv1.2 will be enabled. If you wish to use TLSv1 you can edit the TLS configuration file (tls-default.conf) and add it back to the enabled protocols entry.
MULE-9334: When an SQLException occurs while executing a query, all ResultSets from that DB connection (i.e.: multiple queries in the same transaction) that remain open will be closed.
MULE-9324: When using a File inbound endpoint to poll a directory, an exception will be thrown if the directory to be polled doesn't exist. That exception will be handled by the System Exception Strategy.
MULE-9204: The default authentication method for a token request when using the oauth client credentials grant type will now be basic auth (using client id as user and client secret as password).
    If the previous authentication method is desired instead, then the "encodeCredentialsInBody" attribute of the token-request element should be set to "true".
MULE-9183: Status code for successful one-way operations handled through CXF will be 202 instead of 200
MULE-9041: The HTTP Connector will leave the inbound property http.remote.address with the actual remote address. If an X-Forwarded-For header is present, it will be available as an inbound property.
MULE-9020: BouncyCastle was upgraded to version 1.50.
    Note: DESede algorithm now requires keys of 16 or 24 bytes unlike the prior version which required 16 or 22 bytes.
    Note 2: the bcmail (Bouncy Castle S/MIME API) dependency was removed. If you need any of its functionalities, you must add the library by yourself.
MULE-8963: Exceptions that extend org.mule.api.MessagingException now receive the org.mule.api.processor.MessageProcessor that was executing in the constructor.
MULE-8927: The attributes that end in an endpoint URI (for instance: smtp user and passwords) had to be encoded as a workaround for this issue. That workaround now has to be removed.
	This also affects the result of MEL expressions (for instance, if an expression evaluated to a username with an @ char, it had to be encoded before using it), so a check has to be done to remove all the additional encoding that was placed for working this around.
MULE-8626: The HTTP Connector will now ignore a "Connection" outbound property when responding to a request (listener) or making one (request), instead of transforming it to a header. This means that: if such property is desired, it should be explicitly added as a header using a response/request builder.
MULE-8678: The HTTP Connector will now ignore a "Host" outbound property when making a request, instead of transforming it to a header. This means that: if such property is desired, it should be explicitly added as a header using a request builder.
MULE-8676: The HTTP Connector will now ignore a "Transfer-Encoding" outbound property when sending a response, instead of transforming it to a header. This means that: if such property is desired, it should be explicitly added as a header using a response builder.
MULE-8677: The HTTP Connector will now ignore a "Transfer-Encoding" outbound property when making a request, instead of transforming it to a header. This means that: if such property is desired, it should be explicitly added as a header using a request builder.
MULE-8844: When until-successful throws an exception, it will now be a RetryPolicyExhaustedException wrapping the cause of the exception of the last try, instead of a MessagingException wrapping a RetryPolicyExhaustedException with no link to the actual cause.
MULE-9044: The HTTP Listener will now return a 400 instead of a 500 when an invalid Content-Type is sent on a request. Additionally, in both cases a response body will be present.
MULE-6298: AbstractMessageSequenceSplitter#process will now return null instead of a VoidMuleEvent. This affects only the scenario where the elements of a split collection are filtered out.
MULE-9306: Losing flow and session variables when using MuleClient to dispatch/send an event. Exception strategy not caching exceptions after using MuleClient on a JavaComponent.
MULE-9383: HTTP Connector will allow invalid Content-Type header values. In order to strictly validate them as before, use the mule.strictContentType=true system property.
MULE-9405: MuleException instead of NPE is now thrown when setting a null value for a context-property in an XstlTransformation.
MULE-9160: Log4J was upgraded from 2.1 to 2.5.
MULE-9501: The wildcard-filter will only work with prefix (*.log), suffix (java.util.*) or enclosing strings (*util*) patterns, as well as the deprecated payload based filter (java.lang.Throwable+) and regular strings.
    In any other case no match will be possible, regardless of the input. The regex-filter should be used for other cases.
    This also affects the wildcard patterns allowed by the file-wildcard-filter, request-wildcard-filter, expression-filter, message-property-filter, exceptions strategies commit-transaction and rollback transaction exception patterns, wildcard patterns used in expressions, among others (complete list can be found in https://www.mulesoft.org/jira/browse/MULE-9501).
MULE-9522: jruby was upgraded to version 1.7.24. Also, the following dependencies were updated:
    * bytelist: from version 1.0.10 to 1.0.11
    * jcodings: 1.0.10 to 1.0.16
    * jffi: 1.2.9 to 1.2.10 (-native too)
    * jline: removed
    * jnr-constants: 0.8.4 to 0.9.0
    * jnr-enxio: 0.4 to 0.9
    * jnr-ffi: 1.0.4 to 2.0.5 (shaded into mule-module-scripting-jruby)
    * jnr-posix: 2.5.2 to 3.0.27
    * jnr-unixsocket: 0.3 to 0.8
    * joni: 2.0.0 to 2.1.9
    * jruby-core: 1.7.4 to 1.7.24 (shaded into mule-module-scripting-jruby)
    * jruby-stdlib: 1.7.4 to 1.7.24
    * jzlib: 1.1.2 to 1.1.3
    * nailgun-server: 0.9.1 (new)
    * options: 1.3 (new)
    * yecht: 1.1 (new)
MULE-9531: async-http-client was upgraded to 1.9.37.
MULE-9533: JMS Outbound endpoint does not respect response timeout.  Because the JMS outbound endpoint now uses the endpoing 'responseTimeout' attribute it will no longer respect any timeout value set directly on the MuleEvent via API.  To mitigate this, configure the desired timeout via the 'responseTimeout' attribute on the endpoing element.

Migration changes from 3.6.x to 3.7.x

MULE-8298: Spring dependency was upgraded to version 4.1.6.RELEASE.
MULE-8315: the following Apache Tomcat libraries were upgraded form version 6.0.29 to version 6.0.41: annotations-api, coyote, el-api, jasper, jasper-el, jsp-api, juli. Removed catalina-6.0.29.jar as is not needed anymore.
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-8308: jruby was upgraded to version 1.7.4 because of a security issue with previous version. Artifact jruby-complete was removed and replaced with jruby-core and its dependencies.
MULE-8297: CXF was upgraded to version 2.7.15. Also, the following dependencies were updated:
    * jibx-extras: from version 1.2.4.5 to 1.2.5
    * jibx-run: from version 1.2.4.5 to 1.2.5
    * jibx-schema: from version 1.2.4.5 to 1.2.5
    * neethi: from version 3.0.2 to 3.0.3
    * opensaml: from version 2.5.1-1 to 2.6.1
    * openws: from version 1.4.2-1 to 1.5.1
    * wsdl4j: from version 1.6.2 to 1.6.3
    * wss4j: from version 1.6.9 to 1.6.18
    * xmlschema-core: from version 2.0.3 to 2.1.0
    * xmltooling: from version 1.3.2-1 to 1.4.1
    Note 1: If you need to use uri parameters add an org.apache.cxf.interceptor.URIMappingInterceptor interceptor to the CXF service in your flow, see http://cxf.apache.org/cve-2012-5633.html.
    Note 2: jibx binding could have some issues if you use it under Java 8.
MULE-8367: Property http.relative.path was added to the inbound properties of the HTTP listener. This property will reflect the value of the http.request.path property without the basePath part of the corresponding listener.
MULE-7941: Upgraded Quartz to version 2.2.1.
MULE-8260: As ASM 3.3.1 is not fully compliant with Java 8, the class in the packages org.mule.util.scan and org.mule.util.scan.annotations have been deprecated, however you can use them under Java 7.
MULE-7588: Lifecycle has been fixed. Please have the following considerations:
    * Initialisable objects will only be invoked after the registry has instantiated all objects and successfully injected dependencies into them. initialise() is no longer eagerly invoked.
    * JSR-330 annotations are now the recommended way of getting hold of dependencies. Manual lookups through the mule context registry are still supported but not recommended
    * Initialisation is now applied on dependency order. Meaning that if object 'A' depends on 'B' and 'C', mule will guarantee that by the time that 'A' is initialised, 'B' and 'C'
      will 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 will not participate of dependency injection
    * The org.mule.api.registry.Registry.registerObject(key, Object, metadata) method has been deprecated. The metadata will no longer be 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'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 will 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 https://github.com/mulesoft/mule/wiki/%5BMule-3.7.0-M1%5D-Registry-Consolidation,-Lifecycle-fix,-and-Dependency-Injection
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: set-payload element is now implemented using a plain MessageProcessor instead of using a MessageTransformer. This means that <set-payload> will continue working as before unless is used as a transformer. (for example, inside an endpoint)
           To use SetPayloadTransformer in the mule configuration file as a transformer, it must be defined 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 will update the message data type, but instead of using transformer's output data type it will use a merge between payload's and transformer data types.
           If transformer's output data type does not provides mime type and/or encoding, then the original payload data type mime type and/or encoding will be used.
           This can cause that different transformers are applied on an application after the upgrade. In case there is a failure use <set-payload> to set encoding and mime type while maintaining the same payload.
MULE-7990: A new API for object serialization has been added through the ObjectSerializer interface. Please have 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 instance
      will be the one 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're many ways to obtain an ObjectSerializer. Recommended approach
      is 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:

        // returns the default object serializer
        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 will remove 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-8583: async-http-client was upgraded to 1.9.21.
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-8639: Grizzly was upgraded to 2.3.21.
MULE-8645: jasper-jdt-6.0.29 is not included anymore on Mule distributions because of some detected vulnerabilities. In case this artifact is needed, when using drools for example, then manually add it on <MULE_HOME>/lib/opt
MULE-8641: The wrapper.conf file now contains default GC and memory settings configured to improve performance in an environment with 2GB+ memory. If you need to run Mule with less memory, you will need to edit this file.
MULE-8628: The HTTP connector will now ignore it's 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 will always return 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.
MULE-8736: org.mule.api.expression.ExpressionEvaluator interface has a new method, so upgrading custom expression evaluators will require to implement that method or extend from  org.mule.expression.AbstractExpressionEvaluator which provides a default implementation

Migration changes from 3.5.x to 3.6.x

MULE-7774: All date related headers for the HTTP transport are now in GMT following RFC2616. To maintain the previous behaviour where the Date header was in the server's time zone, you can set system property mule.http.dateheaderservertimezone to true.
MULE-7755: Patterns module is deprecated and will be removed in Mule 4.0.
MULE-7857: The RemoteDispatcher and related classes in the client module have been deprecated and will be removed in Mule 4.0.
MULE-7858: Support for spring events and related classes in the spring-extras module has been deprecated and will be removed in Mule 4.0.
MULE-7723: ScriptConfigurationBuilder and related resources have been deprecated and will be removed in Mule 4.0.
MULE-7842: Jersey was upgraded to version 2.11 which implements jax-rs 2.0. Applications using the jersey module will need upgrading. For further reference see Jersey's migration guide at https://jersey.java.net/documentation/latest/migration.html#mig-1.x
MULE-7842: javax.annotation:javax.annotation-api was upgraded to version 1.2. We're now importing this dependency directly while before we did it through the geronimo-specs project
MULE-6866: Groovy was upgraded to version 2.3.7-indy. If this produces any compatibility issues with an existing script you should either update your script (recommended) or go back to a prior version by replacing the groovy jar at MULE_HOME/lib/opt
MULE-7906: Jython 2.7.3b3 is now part of the distribution. You no longer need to install the scripting pack or include it on your app. If this produces any compatibility issues with an existing script you should either update your application/installation (recommended) or replace/delete the jython jar at MULE_HOME/lib/opt
MULE-7740: Rhino 1.7R4 is now part of the distribution. You no longer need to install the scripting pack or include it on your app. If this produces any compatibility issues with an existing script you should either update your application/installation (recommended) or replace/delete the rhino and js-engine jars at MULE_HOME/lib/opt
MULE-7946: The following dependencies were removed from the distribution since they're no longer necessary as 1.7 is now the minimum required JDK version for running mule:
    * geronimo-j2ee-management_1.0_spec-1.1.jar
    * jaxb-api-2.1.jar
    * jaxws-api-2.2.1.jar
    * jsr250-api-1.0.jar
    * jsr181-api-1.0-MR1.jar
    * saaj-api-1.3.jar
    * saaj-impl-1.3.jar

MULE-7949: Guava has been upgraded to version 18.0
MULE-7950: The following Apache Commons dependencies were upgraded:
    * commons-beanutils: from version 1.8.0 to 1.9.2
    * commons-codec: from version 1.3 to 1.9
    * commons-exec: from version 1.1 to 1.2
    * commons-net: from version 2.0 to 2.2
MULE-7951: xmlunit has been upgraded to version 1.5
MULE-7919: json-schema-validation-filter in the json module was deprecated and will be removed in Mule 4.0. Use the new validate-schema message processor instead.
MULE-7919: The following classes have been deprecated. Use JsonSchemaValidator instead
    * JsonSchemaFilter
    * JsonSchemaJsonValidationFilter
    * JsonSchemaValidationFilter
    * JsonSChemaXsdValidationFilter
MULE-7919: The following dependencies were upgraded:
    * jackson-databind: from version 2.1.1 to 2.4.3
    * joda-time: from version 1.6 to 2.5
MULE-7919: The dependency org.kitchen-eel:json-schema-validator was removed and replaced with com.github.fge:json-schema-validator:2.2.5. If you still need to use that dependency, you can safely add it back to your application/runtime.
MULE-7987: The following dependencies were upgraded:
    * saxon: from version 9.1.0.8 to 9.6.0.1-HE
    * woodstox-core-asl: from version 4.1.4 to 4.4.1
    * stax2-api: from version 3.1.1 to 3.1.4
MULE-7030: The following features have been deprecated in favor of <expression-filter>:
    * jaxen-filter
    * jxpath-filter
MULE-7030: The following features have been deprecated in favor of <expression-transformer>:
    * jxpath-extractor-transformer
    * bean: expression evaluator
MULE-7030: The following features have been deprecated in favor of the new xpath3() MEL Function
    * xpath: expression evaluator
    * xpath2: expression evaluator (in favor of the xpath3() MEL function)
    * xpath() MEL Function
MULE-7030: The xpath-filter element is now namespace aware. If you're using it with XPath expressions which reference custom namespaces, you now have to declare them in a namespace-manager element or use a wildcard (*:/title instead of book:title)
MULE-8001: The xquery-transformer element will now always return a java List when no return type has explicitly been specified
MULE-7983: Devkit based Cloud Connectors with OAuth support will now use the new HTTP connector by default, unless the useTransportForUris configuration flag is set to true (see MULE-8066). The connector-ref attribute now accepts either an HTTP transport 'config' or a new 'listener-config' element. Devkit based connectors using OAuth1 will not support the new HTTP connector
MULE-7731: The default value of the 'cacheJmsSessions' attribute in the JMS connector element is now 'true' to provide better out of the box performance.  This attribute can be set 'false' to disable caching as in 3.5.
MULE-7731: The <jms:caching-connection-factory> has been deprecated.  It can still but used in 3.6, but it not necessary given that from Mule 3.6 JMS connections cache Sessions/Producers by default when a CachingConnectionFactory has not been configured explicitly.
MULE-7731: org.mule.transport.jms.xa.ConnectionFactoryWrapper has been renamed to org.mule.transport.jms.xa.DefaultXAConnectionFactoryWrapper.
MULE-8082: XStream was upgraded from version 1.4.2 to 1.4.7
MULE-8083: JXPath expression evaluator no longer accepts external entities when payload is not already a Document
MULE-7736: From Mule 3.6, SEDA queues used with the 'queued-asynchronous' processing strategy are now bound to four times the maximum number of active threads by default.  This change permits stages to be decoupled as well as peaks in traffic to be handled while avoiding OutOfMemoryException's.  The queue size can be increased in configuration or set to '-1' for 3.5 behaviour (unbound).
MULE-8004: Examples are no longer included in the distribution. Check the README file in the examples folder for more information
MULE-7736: From Mule 3.6, SEDA queues used with the 'queued-asynchronous' processing strategy and services are now bound to four times the maximum number of active threads by default.  This change permits stages to be decoupled as well as peaks in traffic to be handled while avoiding OutOfMemoryException's.  The queue size can be increased in configuration or set to '-1' for 3.5 behaviour (unbound).

Migration changes from 3.4.x to 3.5.x

MULE-6968: In the previous version, requests to "/" were only received by an HTTP endpoint when no path was defined, and rejected if path was set to "" or "/". Now requests are received by the endpoint in any of the three cases.
MULE-7013: keepSendSocketOpen attribute in the HTTP/S connector is deprecated. It is inherited from TCP Connector but has no effect on outbound HTTP connections and will be removed in the future.
MULE-7023: The keep-alive attribute in inbound and outbound HTTP/S endpoints is renamed to keepAlive.
MULE-7011: org.mule.util.queue.Queue class now has a clear() method to discard all elements in the queue while leaving the queue still usable. If you have your own implementation of a Mule Queue you'll need to implement it
MULE-7010: ObjectStore class now has a clear() method which discards all elements while leaving the store still usable. If you have your own implementation of ObjectStore you'll need to implement this method
MULE-7090: Mule will use the default security provider and TLSv1 as default algorithm for secure socket connections
           tlsProtocolHandler attribute from TLS configuration in SSL/TLS/smtps/jettry https transports is deprecated and will
           be ignored. Mule uses the default settings defined in the JVM platform. This parameter is no longer needed in
           supported JDKs.
MULE-7061: Jetty transport is now using Jetty 8. Applications using a custom jetty.xml configuration file must update the Jetty classes referenced in this file due to package names changed from version 6 to 7, as explained here: http://wiki.eclipse.org/Jetty/Starting/Porting_to_Jetty_7/Packages_and_Classes
MULE-7138: MD5MuleEventKeyGenerator is now deprecated, a new implementation is provided: SHA256MuleEventKeyGenerator.
MULE-7097: A new configuration file 'conf/tls-default.conf' has been added. This file defines two properties, that allow to limit the cipher suites and protocols used by Mule in SSL sockets.
MULE-7103: There is now a new system property 'mule.security.model' that may be used to alter the security setup of Mule and its modules. If not defined, or defined with the value 'default',
            no restrictions will apply and Mule will read the TLS configuration from the file 'conf/tls-default.conf'.
            If defined with the value 'fips140-2' Mule will work with a Fips compliant security model: any cryptographic modes of operation not approved in the standard will be disabled
            (the pgp module will be disabled, and the TLS configuration properties will be read from 'conf/tls-fips140-2.conf'). Note that full compliance also requires a certified JCE provider installed.
MULE-7390: The following transformers no longer support external entities out of the box: xslt-transformer, dom-to-xml-transformer, xml-to-dom-transformer
            dom-to-output-handler-transformer, xquery-transformer. For cases in which external entities processing is needed, the attribute acceptExternalEntities has been added
            as optional (defaults to false). Use this attribute with extreme care in cases in which you trust the source only.
MULE-7425: xpath() MEL function no longer changes the message payload when a source is provided. So for example, the expression xpath('catalog/cd/title') may change the message payload, while xpath('catalog/cd/title', flowVars['xml']) will never do
MULE-7439: org.mule.transport.http.servlet.MuleHttpServletResponse.formatDate now receives a StringBuilder instead of a StringBuffer
MULE-7428: Mule queues underlying implementation has changed. To get previous behaviour you can set system property mule.queue.objectstoremode=true. Old classes were deprecated and moved to package org.mule.util.queue.objectstore
MULE-7362: MEL expressions now propagate nulls instead of raising an exception. For example a.b.c would previously raise a NPE if a.b was null. It will return null now.
MULE-7513: Attribute secondsBetweenRetries has been deprecated in favor of a new attribute called millisBetweenRetries. This change is backwards compatible, you can still use secondsBetweenRetries although it's not recommended. Setting both attributes at the same time will result in a configuration error
MULE-7386: Class org.mule.module.management.agent.JmxAgent has been renamed to org.mule.module.management.agent.JmxApplicationAgent
MULE-7536: Mule distribution does not provide a lib/shared/default domain for sharing class loading. Now we provide a default mule domains under domains/default which serves the same purpose and more. You can still use the old shared class loading mechanism by creating the folder lib/shared/default
MULE-7524: Encoded mule expressions in dynamic endpoints address components are not supported anymore (ie: %23[expression] must be #[expression])
MULE-7546: Implementations of org.mule.api.MuleMessage now need to implement clearAttachments() which was added to the interface. Implementations that extend org.mule.el.context.AbstractMapContext must now implement clear() given this method has been removed from the abstract implementation.
MULE-7612: maps returned by queries using the Database connector can have different keys as now column's aliases are used instead of column's names.
MULE-8066: Since 3.6 MuleClient uses the new HTTP module for processing HTTP URLs. To use the previous behaviour use the attribute 'useTransportForUris' in the http:config  element that's located inside the mule configuration element. You can also set this globally by using the system property 'mule.http.useTransportForUris'.
