This section describes how to debug a Mule application using Studio's Visual Debugger or alternative troubleshooting techniques. The Visual Debugger allows setting breakpoints to inspect message contents at different points in a flow. When running in debug mode, the debugger perspective opens and pauses at breakpoints. Alternative techniques include configuring stacktraces, debugging outside Studio by enabling remote debugging in Eclipse or when running standalone, and using logging statements.

2. This section describes how to debug your
Mule application using:
 Studio Visual Debugger
 Troubleshooting

3.  Studio’s Visual Debugger allows you to run
your application in Debug mode, stopping
execution to check the contents of a message at
previously-specified building blocks.
 To do this, you set a breakpoint at any building
block in your flow that you wish to check or test
(see image below). When you run your
application in Debug mode, the application
stops immediately after executing the building
block with the breakpoint. Using the Mule
Debugger View, you can browse through the
contents of the message as it exists at that point
in the flow, and evaluate Mule
Expressions against the message.

4.  Complete the following macro-steps to use
the Visual Debugger in Studio.
1. Setting Breakpoints
2. Running in Debug mode
3. Viewing message data at a Breakpoint
4. Resume application execution.
5. Repeat step 3 with the next building block
with a breakpoint, if any.

5.  Right-click on building block, then
select Toggle breakpoint.

6.  In the Package Explorer pane, right-click on
your application, then select Debug As> Mule
Application. Studio begins running the
application in Debug mode, and displays
the Confirm Perspective Switch window.

7.  When you begin running your
application in Debug mode, Mule opens
the Mule Debug perspective. Until a
message arrives at the first breakpoint,
the Mule Debugger View in the console
displays a message that reads,
"Connected with mule ESB. Waiting for
a mule message to arrive!“
 The image below illustrates the Mule
Debug perspective.

10.  This section introduces a number of
techniques useful in troubleshooting
Mule problems and in gathering
information for technical support.
 Configuring Mule Stacktraces
 Debugging Outside Studio
 Logging

11.  By default Mule will filter out some internal
class references from stack traces to produce a
more readable output. This behavior can be
controlled one of three ways:
 Command-line arguments
 Setting properties in Mule Studio
 Using JMX

12.  In Anypoint Studio, you can use
the Studio Visual Debugger to help you
troubleshoot your app. If you’re creating
your Mule app outside Studio, you can
resort to the following options:
 When Running From Eclipse : Select the
"Debug As > Mule Server" start-up mode
from your configuration file. Any
breakpoint you will have set in your
custom code or Mule’s source code will
suspend the execution and will take you
to Eclipse’s Debug perspective.

13.  When Running Mule Standalone : You
need to start Mule with the -debug to
activate remote debugging, which gives (on
Linux):
$MULE_HOME/bin/mule –debug
 With this option, Mule will start normally
but the only difference being the following
message logged in the console:
Listening for transport dt_socket at
address: 5005

14.  The less high-tech and most popular of all
debugging techniques is the usage of log
statements in order to follow the evolution of an
application’s state. In Mule, the state you’re
interested in resides in the messages that are
flowing through your configuration and,
possibly, custom code.
 If you’re running your Mule configuration from
Eclipse, the log outputs are visible right in Eclipse
console window. If you’re running Mule from the
command line, the logs then are visible in your
OS console.