This blog is the formal introduction to the CRaSH console for Mule on which
I've been working for the past month or so. I've decided to interview myself
about it because, hey, if I don't do it, who will?
What is CRaSH for Mule?
It is a shell that is running embedded in Mule and that gives command-line
access to a variety of Mule internal moving parts. It's built thanks to the
excellent CRaSH project, a toolkit built by Julien Viet and sponsored by eXo
Platform, which allows the easy creation of embedded shells.
What can we do with it?
Well, it's easy to find it out. Let's connect to CRaSH for Mule and ask for
As you can see the range of actions include gathering information, like
statistics and names, but also performing actions, like restarting a
connector or even stopping the broker.
Why is it better than JMX?
Behind the scene CRaSH for Mule relies on JMX so ... (more)
To be able to do anything useful, an ESB must be configured with all sorts of
parameters, from endpoint connection URIs to message transformation scripts
to content-based routing definitions. Moreover, ESBs like Mule can host
custom components, which will process messages and perform user-specific
actions on them.
Deploying a new version of an ESB configuration raises the question of
whether it will break anything. How can we build confidence that everything
will be just fine? If unit testing did it for standard software development,
what can it do in the realm of the ESB? Since... (more)
One of the very first CTO-grade decision I had to take in the making of
Snoget was to pick what would become our main transactional persistence
engine. Since we're using Erlang exclusively for our production servers, the
solution seemed easy: use Mnesia. But I settled for PostgreSQL.
At this point, anyone who's been dealing with O/R mapping (like Ted Neward
who said: "Object/relational mapping is the Vietnam of Computer Science"),
should cry fool: Mnesia would offer me persistence without any impedence
mismatch with the application runtime environment and I preferred a SQL
In Mule ESB, outbound dispatching to a destination whose address is known at
runtime only is a pretty trivial endeavor. A less frequent practice consists
in programmatically defining inbound service endpoints.
I recently had to do such thing for a little side project I'm running where
Mule is used as a frontal bus and load throttler in front of a R nodes
exposed over RMI. The goal was to have a non-fixed number of file inbound
endpoints defined in a simple properties file and declare them on a
particular service during the initialization sequence of Mule.
As an integration framewo... (more)
Vancouver Erlang Meetup cferl & Mule Transport PlugView more presentations
from David Dossot.