Logging With Mule ESB 3.x

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

Mule 3.1.2 introduced new logging features:

  1. Log file per-application

  2. Applications can override default logging configuration

  3. Logging configurations can be reloaded on the fly without restarting an app or Mule.

These features are supported in standalone Mule only, no embedded support possible.


  1. Both log4j.xml and log4j.properties formats are supported. See http://wiki.apache.org/logging-log4j/Log4jXmlFormat

  2. log4j.xml takes precedence over log4j.properties if both found

  3. Switching log configuration formats on the fly isn’t supported. I.e. dropping a log4j.xml in when the system was configured using log4j.properties won’t trigger the re-configuration. However, individual app re-deployment can change logging format (new config will be monitored once the app is done redeploying).

  4. $MULE_HOME/conf/log4j.xml/properties is a top-level (container) log configuration.

  5. Mule monitors the log config file for changes every 10 secs

  6. For on-the-fly log config changes to happen, the config file must be a physical file on a disk, not a resource in a jar. In case of a jarred configuration file, logging will be configured once on startup without support for dynamic reconfiguration. In practice, this simply means that one has to put log4j config files in the app’s 'classes' directory.

  7. If there’s an error in the logging config file, the logging subsystem will become unavailable and produce no output. Simply correct the error and save changes, Mule will pick them up in 10 seconds and reconfigure logging.

  8. By default, dedicated log file is created for each app. All log files are located in $MULE_HOME/logs

  9. Default filename pattern for a per-app log is ‘mule-app-myapp.log”, where ‘myapp’ is the name of the app.

  10. Default appender is a DailyRollingFileAppender, for past dates other than today a datestamp is added to the filename in the ‘yyyyy-MM-dd’ format

  11. An app may optionally override logging configuration

  12. Same rules about xml- vs properties-based config preference apply

  13. Same rules about on-the-fly changes to logging configuration file apply

  14. When an app overrides logging configuration, it should configure full logging including the root logger, appenders, etc. This also means that full power of log4j can be leveraged.

  15. For convenience $\{mule.home} can be used in log4j config settings for file paths.

  16. It is possible to use the old-style single-file logging (note that dynamic log re-configuration won’t be supported either). Specify -Dmule.simpleLog JVM startup property (actual value of the property doesn’t matter, only its presence)

Was this article helpful?

💙 Thanks for your feedback!

View on GitHub