The Mule ESB team is pleased to announce the next milestone towards our final Mule 3.0 release. Recent work includes the following areas:
Hot Deployment – Mule now supports multiple applications running within the same Mule instance and deployment descriptors for specifying the contents of your deployment (e.g., multiple configuration files). Most of the Mule examples have been converted to the new deployment format*. If you have not yet read about the application deployment model new to Mule 3.0, read this blog post.
Message Exchange Patterns – Message Exchange Patterns (a.k.a. MEPs) give you more explicit and flexible control over the way messages flow through Mule. For example, you can now specify whether you expect a response on a given endpoint or not (see the new attribute “exchange-pattern” on endpoints). In the future, we may introduce additional exchange patterns that allow for different communication styles as well.
Message Processor API – An architectural change to simplify Mule’s internals and give it the flexibility to implement other patterns in the future which align more closely to specific scenarios beyond the service/component elements which you all know and love.
Flow Construct – A new <flow> XML tag that allows Mule configurations to take full advantage of the flexibility and power of the Message Processor API.
Message Property Scoping – Message properties are now scoped in either ‘inbound’, ‘invocation’ or ‘outbound’ scope. These scopes provide isolation and consistency to the way properties are attached to inbound and outbound messages.
Lifecycle Improvements – Improves behaviour during startup and shutdown of applications, a very important aspect of hot deployment. We have also added support for JSR-250 lifecycle annotations @PostConstruct and @PreDestroy.
Exception Strategy Improvements – Exception strategies were simplified to provide more consistent and predictable error-handling behavior.
CXF – CXF is now both more easily configurable and more flexible. CXF is now configured as a message processor within a flow. This message processor is simple to configure since there is specific XML syntax for each use case: client, server, and proxy.
Jersey – Jersey is now part of the base mule distribution with improvements. Like CXF, Jersey is now both easily to configure and highly flexible. Instead of being an endpoint type, Jersey is now implemented as a type of component that can contain any number of Jersey resources.
As usual, we have continued to port all bug fixes from Mule 2.2.x into this release as well.
Download it!
Release notes
Provide feedback
Enjoy!
* Not all Mule examples have been converted yet, those still to be converted are gpswalker, geomail, notifications and mule-webapp. Additionally, the examples need to be built first using Ant or Maven, this requirement will be removed for the 3.0.0-GA release.
