Mule 3. Rebooted.


Mule 3 Milestone 3 (3.0.0-M3) is ready to hit the streets, and today we’d like to talk about a fundamental transformation that it has undergone. Mind you, it’s not the only one 🙂

Ever since Mule pre-1.0 was out in the wild, there was one thing which many felt missing: “What constitutes a Mule application?”. Most of the time, it was an integral part of any Mule rollout, which wasn’t necessarily a bad thing. Then, we felt (and you raised your voice) that there was so much more that could’ve been done, especially with tools like the new Mule ESB Management Console.

Milestone 3 features an early preview of the new model for deploying Mule applications. Find more detailed docs here, but for most of us, lazy folks, here’s a quick summary for deploying an app ‘foo’:

  • Create a directory under $MULE_HOME/apps/foo
  • Jar custom classes (if any), and put them under $MULE_HOME/apps/foo/lib
  • Put the master Mule config file at $MULE_HOME/apps/foo/mule-config.xml (note that it has to be named mule-config.xml
  • Start your app with mule -app foo

As a bonus, application’s master config file is monitored, so if there are any class changes you want to pick up or simply modify the config, save or touch mule-config.xml and Mule will hot-reload the application.

So, why is this such an important step for Mule? Doesn’t sound like much unless you realize that there can be more than one app, nicely isolated and structured under the apps directory. Some of the goodies one gets are:

  • Applications can depend on different library versions, even if they would conflict before
  • Operations folks would be happy to have clear boundaries for a Mule application to work with
  • Running multiple applications side-by-side (this one is not in Milestone 3, but is coming up)

Before anyone cries ‘application server!’, we’d like to stress that our goal is not to reinvent the wheel, and we’d never chase a mythical compliance with every specification out there. The focus is very pragmatic, and we’d only do something that makes sense for our users and no more.

On this note, I’d like to say that this new model is not officially enabled by default yet, there’s a 1-line config change to make (check the docs). However, we encourage you, the user, to give it a try, provide feedback (praise or complaint, we don’t mind either 😉 ), and share any thoughts and suggestions that you think would benefit you and the community.

Download Mule ESB 3 Community M3

On your mark, get set…

We'd love to hear your opinion on this post

9 Responses to “Mule 3. Rebooted.”

  1. This is great news. How will clusters of Mule servers handle deployments? IIRC, NetBoot was deprecated.

  2. Hi Richard,

    The Mule Management Console will take a spot light here, but it does more than just pushing out apps to remote boxes. If you are familiar with Tcat Console, then versioned deployments, application rollbacks and friends will be familiar.

    Having said that, technically it is possible to have a kind of a farm deployment folder, although it does have its own limitations. Don’t see why this couldn’t be a collaborative community effort 🙂

  3. I’ll take a look at Galaxy and see what it provides and doesn’t provide in this area. Most of the clients I worked with typically look for support in this area so they can have SCM manage deployments easily.

    If you’re on IRC ping me sometime on rburton-


  4. “The Mule Management Console will take a spot light here, but it does more than just pushing out apps to remote boxes.”

    How does the MMC push out apps? I can manually replace files with it, but I see no way to do batch updates

  5. Loki, not sure what you mean by ‘batch updates’. MMC provides an API to do lots of things, check out (in addition to admin shell scripting).

  6. Thats exactly what I was looking for, I think. MMC is taking over from where Galaxy (Mule Service Repository?) left off?

  7. Nice! Add an archive file format (ala WAR vs. exploded directory), and strong maven build/deploy plugins + supporting archetypes and Mule’s deployment model has definitely just taken a significant turn for the better. The maven plugin support is a huge piece of the puzzle– makes developers’ and config management folks’ lives much easier.

  8. […] 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. […]

  9. […] in the name? Some of you may have met this baby in its infancy before, or maybe were around to see it make first steps. Those would be even more pleased to see it […]