Sneak Peak at Mule 3.x: It’s Hot!


We’ve been busy working on Mule releases recently, so this blog hasn’t had as much developer voice as it deserves. Working on things like WebSphere MQ can be demanding, which is another reason to appreciate the all-new shiny WebSphere MQ connector in Mule Enterprise 2.2.1. Makes one’s life much much easier.

That is not to say we didn’t cure our (and your) itch for new features. Many great ideas are currently being born, killed and re-born again, and I’m happy to announce an official user-facing kick-off of Mule 3.x (yes, it’s our third one already!) with the availability of the bleeding-edge 3.0 Milestone 1 Build.

Many features in this build aren’t obvious on the surface, like our massive private Bamboo infrastructure behind the firewall – an Octopus would be a more precise name for this highly distributed build monster, and it’s spawning more and more offspring, OMG! :). But although the build may look the same at first glance, there’s a subtle twist. A hot one, or more precisely, a hot-deployment one!

It’s only a start of many more things to come in Mule 3.x, but it’s already worth checking out. We’ve modified the Mule Hello World example so you can try hot deployment right out of the box:

  1. Head over to the Mule downloads page and grab a copy of your own (expand the last section under Development Releases, Latest Developer Milestone Build: Mule 3.0 Milestone 1).
  2. Unpack the archive and set MULE_HOME to point to this directory (no news here, it’s the same steps as before).
  3. Start a shell and change to the $MULE_HOME/examples/hello directory
  4. Build the example by running ‘ant’.
  5. Launch the ‘hello’ script, accepting the license agreement when running for the first time.
  6. Point your browser at this URL: http://localhost:8888/?name=Mule
  7. You’ll see ‘Hello Mule, how are you?’ response
  8. Let’s have some fun now. Edit the file in examples/hello/src/main/java/org/mule/example/hello and modify the chat() method (add a chat line):
    public void chat(ChatString string)
    string.append(" Don't you like it hot?");
  9. Back in the hello directory, execute ‘ant’ again (watch the Mule console for activity).
  10. Refresh http://localhost:8888/?name=Mule
  11. New response: ‘Hello Mule, how are you? Don’t you like it hot?’ And you know the answer 😉

Well, that’s it for a quick preview! Do bug us with any feedback (we know things may not always work in this world):

Either way works: forums and lists have two-way sync.

Here are advanced details on how hot deployment works:

  • Hello example’s ant script does a regular build and copies JARs and config to $MULE_HOME/apps/hello, putting JARs under $MULE_HOME/apps/hello/lib.
  • Currently, only JARs are supported (no exploded archives yet).
  • Put application JARs in this custom lib folder to make them reloadable. Do not put them in $MULE_HOME/lib/user. If you put a duplicate copy in $MULE_HOME/lib/user, hot deployment won’t work.
  • A config file (passed via -config switch) has an optional ‘lib’ folder next to it with application JARs
  • Currently, only the first config will be monitored (if you’re using split configuration).
  • Mule config must be unpacked for now.
  • To trigger redeployment, touch the app config file (or modify and save it). Mule checks every three seconds for changed configurations and classes.

That’s it! Happy hot deployment!

We'd love to hear your opinion on this post

12 Responses to “Sneak Peak at Mule 3.x: It’s Hot!”

  1. Great news ! I have to test this.

    Another point :

    I just have a quick walk through the package.
    I am a bit surprise : Mule 3.0 is still based on CXF 2.1.2 ?
    When is planned a CXF 2.2 version ?
    Is it possible to already switch with Mule 2.2 ?

    Thanks for response,


  2. Mule 3 should be released with CXF 2.2. This was just a very early milestone containing the new Hot Deployment technology and a few other bits.

    Any feedback you can provide (via the forums) would be helpful.

  3. Andrew, does “hot deployment” mean “automatically detect new jars or config files, stop server and run again with new one”? I’m a bit confused about this, I meant this should act as e.g. hot deployment in JEE web container (without stopping whole server). Or am I wrong? Thanks.


  4. Hi Petr, comment notifications must have been disabled, missed your question. Under the hood things are done roughly like in an app server, so the outer process is still running, but the context is redeployed, optionally picking up/loading changes.

  5. Is this feature being enabled by osgi or something else?

  6. No, it’s not osgi, and one doesn’t need osgi to get redeployment.

  7. Could you point me to the API methods that enable this feature? I have my own configuration builder so i’m wondering what i need to do programmatically to enable this in my app.

  8. Adam,

    I’ve posted some technical details before:

    Although it’s a bit outdated (current solution moved forward), it will still give one enough tech leads to start with.


  9. What happens to the messages that are already on the bus when redeployment of e.g an existing component is made?

  10. They just go through a regular context.stop() -> dispose() lifecycle.

  11. My question is really: if a mule service component is performing a long-running computation (based on the payload it has received from the bus) , and a new version of that component is deployed, will the computation in progress be completed, or will it be aborted, thus risking that the result of the computatin never reaches the outbound endpoint ?

  12. Jan, Mule will perform a graceful shutdown of your service (wait for all current interactions to end) before shutting it down. Once redeployed the service will continue as normal.