Mule Debugging

1. Mule ESB - Debugging

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

3. Studio Visual Debugger :
 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. Using the Visual Debugger :
 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. 1. Setting Breakpoints :
 Right-click on building block, then select Toggle breakpoint.

6. 2. Running in Debug Mode :
 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. 3. Viewing Message Data at a Breakpoint :
 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.

9. Mule Debugger View :

10. Troubleshooting :
 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. Configuring Mule Stacktraces :
 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. Debugging Outside Studio :
 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. Logging :
 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.

15. Thank Q