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:
- 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).
- Unpack the archive and set MULE_HOME to point to this directory (no news here, it’s the same steps as before).
- Start a shell and change to the $MULE_HOME/examples/hello directory
- Build the example by running ‘ant’.
- Launch the ‘hello’ script, accepting the license agreement when running for the first time.
- Point your browser at this URL: http://localhost:8888/?name=Mule
- You’ll see ‘Hello Mule, how are you?’ response
- Let’s have some fun now. Edit the ChitChatter.java 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(chitchat);
string.append(" Don't you like it hot?");
}
- Back in the hello directory, execute ‘ant’ again (watch the Mule console for activity).
- Refresh http://localhost:8888/?name=Mule
- 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):
- Mule forums
- Mailing Lists
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!