What's New in Mule Version 2.0

This page describes the major new changes that were available as of Mule 2.0. Mule 2.0 is an older release. For a list of changes in the latest release, see What's New in This Release. For a list of the issues that were fixed in each point release, click here.

XML Schema

The principal new feature of Mule 2.0 is a powerful new schema-based configuration style leveraging Spring's Extensible XML Authoring. To get started converting from Mule 1.x, see Migrating Mule 1.x to 2.0.

For examples of the new configuration style, see the example applications that come in the Mule distribution or some of the functional tests, especially for transports (transports/xxx/src/test/resources/*.xml).

The rest of this section describes the XML-based schema features in more detail.

Simplified Configuration

• All available config options are provided to you by your IDE (via XML schemas) and the correct syntax is auto-completed for you (tested with Eclipse and IntelliJ)
• No need to remember, type, or copy/paste long class names, they are now hidden from the user (unless you want to provide a custom class)
• It's harder to shoot yourself in the foot because the Namespace Handlers help validate your config before Mule even starts up.
• No longer having class names in your config files should make upgrading Mule less likely to break your configs ("less brittle").

Transport-Specific Endpoints

Endpoint configuration has been greatly improved thanks to the benefits of schema based configuration along with our "Bean Definition Parser Toolkit" and the separation of inbound/outbound/response endpoints into their own elements and the ability to define transport specific endpoints in their own namespace. This is very powerful in that each and every endpoint type (transport + context (inbound/outbound)) can be defined in the schema(s) so that class names and properties are avoided and only the relevant transport/context attributes and elements are available. Not only does this make for a typed easier-to-read configuration file, but it also makes endpoint configuration, in combination with your favorite XML editor, a pleasure with auto-completion.

Configuration Namespaces

• Configuration elements are organized into modular, transport-specific namespaces so that you only need to include the namespaces for those modules used by your Mule config.
• This modularity means that new modules/transports developed by you! can have their own custom namespace.
• For a guide on creating a new Configuration Namespace, read [Creating a Custom XML Namespace].

Bean Definition Parser Toolkit

What Spring's Extensible XML Authoring has let us do is basically create a Domain-Specific Language for configuring Mule. This DSL is based on what are called Bean Definition Parsers. Spring itself provides many classes for creating your own Bean Definition Parsers, but Mule has built on that foundation to create its own "BDP Toolkit" which helps transport authors (such as those working on MuleForge projects) easily add new configuration elements. Common cases like maps, list elements and references are handled automatically, while parsers for more complex configurations can be assembled from simpler sub-components using simple combinators.

A Spring-ier Mule

Spring being the default configuration mechanism for Mule 2.0 also brings other benefits:

• Spring is the industry-leading framework for "wiring" and configuring Java applications, much more robust than the old Commons Digester mechanism
• Common Mule configs are simplified by the Namespace Handlers while custom configs can use standard Spring config syntax
• You get the full features of Spring for free within your Mule:
  • Spring AOP
  • Spring resource loading
  • Spring modules support (JNDI, Hivemind, EJB)

Architectural Improvements

In addition to the user-facing XML config, we've also been working hard on architectural improvements to make Mule more robust and to pave the way for new, powerful enterprise features in future versions of Mule. We have taken advantage of this new major release to make some API modifications which give a range of improvements that could not have been introduced with earlier versions.

MuleContext and Registry

The old monolithic MuleManager is gone in 2.0, replaced by a MuleContext and one or more internal Registries. The MuleContext is injected into any entity which implements the MuleContextAware interface, and is used to access the Registry among other things.

The SpringRegistry is basically a facade on Spring's ApplicationContext (populated at startup), and is read-only. There is also a TransientRegistry (read-write) into which entities may be registered after startup. The Registry architecture will continue to evolve a bit in future releases and will form the basis of OSGi support in Mule.

MuleDescriptor -> Service/Component

The MuleDescriptor in Mule 1.x combined all aspects of a Mule service/component together (routers/endpoints, exception strategy, implementation class, singleton/poooled, etc.) This has been removed in 2.0, and in its place a clearly-separated Service and Component model have been introduced. The Component consists of your "Plain Old Java Object" and any configuration having to do with the lifecycle of that object, e.g., the object might be a singleton instance, pooled, or looked up from an external source via JNDI. The Service then builds on the Component by adding inbound/outbound endpoints + routers, exception strategies, etc.

Endpoints

We took the opportunity to make some architectural improvements to endpoint creation, lookup and global endpoint configuration and usage. This work consisted of general consolidation and clean-up of endpoint creation and lookup logic through the introduction of the EndpointBuilder and EndpointFactory along with some work to ensure endpoints are immutable once created.

• EndpointBuilder is a stateful builder which constructs endpoint instances for a given type (inbound/outbound/response) based on how the endpoint builder has been configured. When endpoints are configured via spring EndpointFactoryBean's are used which extend EndpointBuilder such that the endpoint builder is configured from spring and is then invoked to create endpoint instances.

• EndpointFactory is a stateless factory used to obtain endpoints given the endpoint uri or global endpoint name (uri is substitutable with name). The factory deals with all the endpoint lookup and creation logic delegating to EndpointBuilder's for creation of new endpoint instance if required.

Streaming and Auto Transformations

Mule 2 features much improved streaming and transformation capabilities. Many users will notice a performance boost by upgrading. Now, any transport that supports streaming (i.e. HTTP, File, etc) will pass a stream as the message payload instead of loading the stream into memory.

Mule now also supports intelligent, efficient transformations. It can auto-detect the required type for a component and transform the stream without any extra configuration. For instance, if you have a component which receives a String and it is wired up to HTTP, Mule will take the HTTP InputStream and convert it to a String without an additional transformer configuration.

There is now no need to configure a Streaming model, implement a StreamingService API, or use a UMOStreamMessageAdapter. These classes have all been removed. Data is not consumed from a stream payload until it is required. The payload of the message automatically becomes the data consumed from the stream.

MuleMessage and MessageAdapter

• There is now a much better definition between the roles of these two classes.
• MessageAdapter now ONLY deals with wrapping a message type. There are no methods for converting the payload to String or byte[] array. getPayloadAsString() and getPayloadAsBytes() methods have been removed.
• MuleMessage provides access to the UMOMessageAdapter properties, payload and attachments. It also provides methods for working with and changing the message payload.
• The MuleMessage.getPayload(Class) is used for obtaining the payload in different formats (but doesn't change the payload)
• The MuleMessage.applyTransformers(List) will apply a list of transformers to the message payload. This WILL change the message payload. This method removes the need to copy the current message once the payload changes.
• The MuleMessage still exposes getPayloadAsString() and getPAyloadAsBytes() methods.

API

The API was re-organised taking advantage that 2.0 is a major release to update outdated packages and interface names and improve consistency. Interfaces no longer are prefixed with "UMO", and are now in "org.mule.api" rather than "org.mule.umo. Also 'org.mule.providers' was renamed to 'org.mule.transport' and 'org.mule.samples' to 'org.mule.example'.

Spring XML Configuration

MuleXMLConfigurationBuilder in mule-core was moved to the "spring-config" module and renamed as SpringXMLConfigurationBuilder. In order to use XML configuration, you will now need to include the "spring-config" module on your classpath.

ConfigurationBuilder + MuleContextFactory

The monolithic ConfigurationBuilder API was improved so that it now simply configures an existing Mule instance and a MuleContextFactory interface was introduced for creating a new MuleContext. A DefaultMuleContextFactory is provided with methods that allow MuleContext creation and configuration in a manner similar to the old MuleXMLConfigurationBuilder. Additionally, the QuickConfigurationBuilder has been removed, as it provided minimal functionality and is no longer needed.

Miscellaneous Improvements

• A more consistent, extended interface to the TCP socket based transports (and the SSL/TLS configuration)
• Moved the receive method from the Dispatcher into a new Requester interface with corresponding transport property
• More efficient handling of notifications

XFire Deprecated in Favor of CXF

As of 2.0-RC3+, the XFire connector has been deprecated in favor of the CXF Transport and moved to the MuleForge. This was done for the following reasons:
1. CXF is considered the next version of XFire and can generally deploy your XFire services with no changes. It also has much improved WSDL & WS-* compatibility.
2. The XFire libraries conflicted with CXF. This means that it was impossible for the Mule distribution to include both CXF and XFire, even if XFire wasn't considered deprecated.
3. The CXF connector has much improved support for WSDL-first services and clients.