Nav

Logging

The less high-tech and most popular of all debugging techniques is to use log statements 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 Anypoint Studio, the log outputs are visible right in Anypoint Studio’s console window. If you’re running Mule from the command line, the logs are visible in your OS console.

Mule’s standalone logging configuration is stored in <Mule Installation Directory>/conf/log4j2.xml: edit this file if you need to change the verbosity of the log output.

Note: If you are using Anypoint Studio, the log output appears in the .mule directory of your Studio workspace. For example on a Mac, for an application called Basic Tutorial, the log output is in this file:

/Users/me/AnypointStudio/workspace/.mule/logs/basic_tutorial.log

Logger Component

The Logger component is a quick and easy way to log the payload or metadata of an in-flight message. Add it anywhere in a message flow you want to probe your message:


         
      
1
2
3
4
5
6
7
<flow name="FlowWithLoggers">
  <http:listener config-ref="HTTP_Listener_Configuration1" path="/hello" doc:name="HTTP"/>
  <logger level="INFO" message="Payload received from HTTP: #[payload]" doc:name="Logger-before"/>
  <base64-encoder-transformer/>
  <logger level="INFO" message="Payload after base64: #[payload]" doc:name="Logger-after"/>
  <vm:outbound-endpoint path="next.in.line" />
</flow>

Default Behavior

If nothing is specified in the Message field, the logger logs the entire Mule message, including all session, inbound and outbound properties, as well as flow variables. As it could be very verbose to show all the contents of everything, the contents of the payload aren’t shown, only its type.


         
      
1
2
3
4
<flow name="FlowWithEmptyLogger">
  <http:listener config-ref="HTTP_Listener_Configuration" path="/test" doc:name="HTTP"/>
  <logger level="INFO" doc:name="Log message"/>
</flow>

Best Practice - Differentiate Instances

If a flow uses several loggers, add some fixed text in the logger’s message to identify where it was generated:


         
      
1
2
3
4
5
6
7
<flow name="FlowWithLoggers">
  <http:listener config-ref="HTTP_Listener_Configuration1" path="/hello" doc:name="HTTP"/>
  <logger level="INFO" message="Message before base64: #[message]" doc:name="Log message before"/>
  <base64-encoder-transformer/>
  <logger level="INFO" message="Message after base64: #[message]" doc:name="Log message after"/>
  <vm:outbound-endpoint path="next.in.line" />
</flow>

Using Script Component as a Logger

If you need more details about the message, a simple scripted logging component like the following can come handy:


         
      
1
2
3
<scripting:script name="Logger" engine="groovy">
  <scripting:text>log.info(message); log.info(payload); message</scripting:text> </scripting:script>

You can reference the script component from anywhere in your flow(s) using the name you give it, in thise case "Logger":


         
      
1
2
3
4
5
6
7
<flow name="FlowWithLoggers">
  <http:listener config-ref="HTTP_Listener_Configuration1" path="hello" doc:name="HTTP"/>
  <scripting:component script-ref="Logger" />
  <base64-encoder-transformer/>
  <scripting:component script-ref="Logger" />
  <vm:outbound-endpoint path="next.in.line" />
</flow>

Editing Mule Logging Configuration

You can configure what gets logged, where it gets logged, and how by editing a configuration file from your Studio project or in a folder in your standalone Mule server’s $MULE_HOME directory. For instructions on how to modify the file, see Logging in Mule.

See Also