Skip to content

Latest commit

 

History

History
84 lines (64 loc) · 3.91 KB

1.4-migration-guide.adoc

File metadata and controls

84 lines (64 loc) · 3.91 KB

1.4 Migration Guide

There are some changes in 1.4 that may break compatibility from 1.3 depending on the way you are using Mule. The following describes those changes and how to migrate.

Xml Configuration Changes

Using Split configuration files

When splitting Mule Configuration files In Mule 1.3.3 it was possible to put a <mule-descriptor> element in a single mule XML configuration file i.e.

<mule-configuration>
    <mule-descriptor name="foo" className="org.Foo"/>
</mule-configuration>

This no longer works in Mule 1.4 instead you have to declare all <mule-descriptor> elements in a <model> element. i.e.

<mule-configuration>
    <model type="seda" name="main">
          <mule-descriptor name="foo" className="org.Foo"/>
    </model>
</mule-configuration>

If you want to use the same <model> for every <mule-descriptor> across multiple configuration files you can declare the main model (as above) in the first first file to be processed and then use inherited models in the other configuration files, i.e.

<mule-configuration>
    <model type="inherited" name="main">
          <mule-descriptor name="bar" className="org.Bar"/>
    </model>
</mule-configuration>

Notice the only difference is that the <model> type is inherited and the <model> name remains the same.

Deprecated configuration elements

Some configuration elements and attributes have been deprecated. These will still work in 1.4 but will be removed for Mule 2.0.

  • The following attributes have been deprecated on the _<mule-descriptor> _ element: inboundEndpoint, outboundEndpoint, inboundTransformer, outboundTransformer and responseTransformer.
    These should be used within here i.e. <inbound-router> and <outbound-router> elements.

  • <endpoint-identifier> elements have been removed in favor of using <global-endpoint> elements since global endpoints allow you to associate not only a logical name to a physical address, but also transaction security and transformer information.

API Changes

Transformers and UMOMessage

Some transformers (e.g. SerializableToByteArray) can handle UMOMessages differently from other objects; this capability could be switched on by setting a common property sourceType. This turned out to be confusing; only those transformers that implement this behaviour now have a property acceptUMOMessage which can be toggled to enable/disable the extra functionality. The sourceType property has been removed. Instead of:

<property name="sourceType" value="UMOMessage" />

use:

<property name="acceptUMOMessage" value="true"/>

when configuring a transformer.

Transport changes

The entire transport layer (i.e all classes implementing UMOConnector/UMOMessageDispatcher etc.) received a significant overhaul for correctness, ease of use and scalability. Most notably it is now no longer possible to get programmatic access to a connector’s message dispatchers; for sending an event programmatically instead of using:

// assume ep is an UMOImmutableEndpoint
ep.getConnector().getDispatcher(ep).dispatch(event);

please use the following, much simpler:

// assume ep is an UMOImmutableEndpoint
ep.dispatch(event);

Unfortunately not all API changes could be finalized for 1.4.0, which is why we recommend that people with custom transports hold off migrating until 1.4.1. More detailed changes and instructions will be provided in a dedicated transport migration/architecture guide.