Como consecuencia de mi pequeño experimento de la semana pasada, aprendí alguna que otra cosa interesante sobre los logs de symfony.

En concreto, el núcleo de symfony viene con varios loggers interesantes, a saber:

• sfNoLogger: Es el “anti-logger” ya que no hace nada. Es el utilizado por defecto en el entorno de producción.
• sfVarLogger: Guarda los mensajes de log en una variable interna, llamada … logs! Se utiilza como clase padre para implementar sfWebDebugLogger
• sfStreamLogger: Vuelca los mensajes de logs sobre un “stream” genérico. Se utiliza como clase padre para implementar sfConsoleLogger que utiliza como stream de salida php://stdout
• sfFileLogger: Escribe los mensaje de log en un archivo que se da como parámetro a su constructor.

Además de estos, symfony añade otro más, sfAggregateLogger que es el utilizado por defecto en el entorno de desarrollo (dev). Este logger nos permite mostrar los logs de salida a través de tantos loggers como queramos simplemente añadiendo el nuevo log a lista, para ello, o bien utilizamos el método sfAggregateLogger::addLoggers($loggers) o bien los cargamos directamente mediante el archivo factories.yml:

#/app/config/factories.yml
 
logger:
  class: sfAggregateLogger
  param:
    loggers:
      sf_web_debug:
        class: sfWebDebugLogger
        param:
          level: debug
          condition:       %SF_WEB_DEBUG%
          xdebug_logging:  true
          web_debug_class: sfWebDebug
      f_twitty_logger:
        class: fTwittyLogger
        param:
          user: fTwittyLogger
          pass: symfony

En el ejemplo anterior estaríamos utilizando dos logger, sfWebDebugLogger y nuestro logger propio fTwittyLogger