LogBox : Enterprise Logging & Messaging
7.x
7.x
  • Introduction
    • Contribution Guide
    • Release History
      • What's New With 7.2.0
      • What's New With 7.1.0
      • What's New With 7.0.0
    • Upgrading to LogBox 7
    • 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 Logging Levels
      • Adding Categories Granularly
      • Configuring The Root Logger
  • Usage
    • Using LogBox
    • Using a Logger Object
      • When To Log
      • ExtraInfo Serialization
    • 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 GitHub
Export as PDF
  1. Usage
  2. Using a Logger Object

ExtraInfo Serialization

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

  1. The message to log as a string or a closure that returns the message

  2. An extraInfoargument, which can be anything you like.

This extrainfo argument can be a simple value, a CFC, a complex object, or 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 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's an exception, marshall it to JSON

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

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

$toString() Convention

As you can see from the algorithm above, you can use the extraInfo argument to your benefit to save serialized data representations to the appenders and then retrieve or re-inflate them later. The $toString() convention is great because you can control how a CFC will serialize to its string representation. Let's see an example of 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 );
}
PreviousWhen To LogNextAppender Properties

Last updated 1 year ago

Was this helpful?