LogBox : Enterprise Logging & Messaging
2.x
2.x
  • Introduction
  • Intro
    • Introduction
      • What's New With 5.4.0
      • What's New With 5.3.0
      • What's New With 5.0.0
      • What's New With 2.1.0
      • What's New With 2.0.0
      • About This Book
      • Author
  • Getting Started
    • Features at a Glance
    • Installation
      • LogBox Refcard
    • Need For Logging
    • How Does LogBox Work?
      • LogBox
      • Appender
      • Logger
        • Logger Category Inheritance
        • Security Levels
        • Dynamic Appenders
      • Layout
  • Configuration
    • Configuring LogBox
      • LogBox DSL
      • Adding Appenders
      • Adding Categories to Specific Loggin Levels
      • Adding Categories Granularly
      • Configuring The Root Logger
  • Usage
    • Using LogBox
    • Using a Logger Object
      • Can Methods For Performance
      • $toString() and ExtraInfo Argument
    • Appender Properties
      • CFAppender
      • ConsoleAppender
      • DBAppender
      • EmailAppender
      • FileAppender
      • RollingFileAppender
      • ScopeAppender
      • SocketAppender
      • TraceAppender
    • LogBox in a ColdBox Application
      • Configuration Within ColdBox
      • Benefits of using LogBox in a ColdBox application
      • Where is LogBox stored in a ColdBox app?
      • LogBox from the ColdBox Proxy
      • The LogBox Injection DSL
  • Extending LogBox
    • Creating Custom Appenders
      • Helper Methods
      • Instance Members
      • Dealing With Custom Layouts
      • Registering Appenders at Runtime
    • Creating a Custom Layout
      • Instance Members
Powered by GitBook
On this page

Was this helpful?

Edit on Git
Export as PDF
  1. Usage
  2. Using a Logger Object

$toString() and ExtraInfo Argument

When using any of the logging methods like info(), debug(), warn(), etc, they all take two arguments:

  1. The message to log

  2. An extraInfoargument which can be anything you like.

This extrainfo argument can be a simple value, a CFC, a complex object and pretty much anything you like. The appenders get this extraInfo argument and process it into their appropriate destinations by serializing its value. This is done by using the following algorithm:

  1. If it is a simple value, then just use it.

  2. If it is an object then check if the object has a method called $toString(). If the method exists, then call $toString() and use its return value.

  3. If it is an object with no $toString() method, then marshall its representation into XML format.

  4. If it is a complex variable like a struct, query, array, etc, then marshall it into JSON format.

As you can see from the algorithm above, you can use the extraInfo argument to your benefit to save serialized representations of data to the appenders and then retrieve or re-inflate them later. The $toString() convention is great because you have complete control on how a CFC will serialize to its string representation. Let's see an example on a simple CFC:

// User.cfc
component{

    function $toString(){
        // return my representation as a comma list of values of my properties
        return "#getName()#,#getAge()#,#getEmail()#";
    }
}

So when this object is sent to a logger's method, it will detect it is an object and the $toString() function exists and call it for serialization.

user = userService.getUser( rc.id );

// need to log it.
if( log.canDebug() ){
    log.debug( "User just got logged in right now!", user );
}
PreviousCan Methods For PerformanceNextAppender Properties

Last updated 7 years ago

Was this helpful?