History
Zend_Log builds on PEAR Log and log4j in ZF1. Zend_Log is a logger instance with at least one writer, and one formatter. Filters can be set within logger and/or each writer.
Problems
- Displays custom
optionaltagsin single line format(like %info% for extras see ZF-10427 or DbWriter mapping see ZF-2658) - Bad design for Zend_Log::factory() (it calls others factories of writer/formatter/filter defined in config)
- Overriding Zend_Log::log() and keep factory behavior (see ZF2-18)
- Reflection is used in Zend_Log::construct() to build priorities name (slow)
- Magic method __call() used for shortcut log an event (slow, and hard to discover API)
Changes
- API discoverable (priority as method: debug(), info(), notice(), etc)
- Fixes XML formatter validation (prolog XML, and missing root node)
- Improve Simple Formatter
- Improve extras informations in some writers/handlers
- Use the broker to review factory (ZF2 flavor)
- Add event for log() method (ZF2 flavor)
- Create LoggerAware for Di
- Refactor filter chain mecanism (Filter\FilterChain or Iterator)
- Writer interface can extend FilterAware interface (common behavior between Logger and Writer)
- Separate responsability: create an LoggingEvent/Record class
Proposed Improvements
- Create Loggable/Logging interface for common log methods
- New formatter (json)
- Logger::setEventItem() enchancements in plugins (IP, User agent, better stack trace, extract of source code, etc)
- Renderer for exceptions, array, string object, event, etc (format exception instead of __toString())
- Separate responsability: error handler with ErrorException for debug (set level between notice and error)
- Provide some listeners to help debug in some workflows like MVC, events, etc (ZF2 flavor)
- Add PHP 5.3 flavors with lambda functions/closures, etc
- New writers/handlers (Queue, Ticket in Redmine/HTTP?, socket?)
- Check issues/wishes on JIRA (ZF-1833, ZF-2428, ZF-2618, ZF-2658, ZF-3107, ZF-3108, ZF-3581, ZF-5741, ZF-6972, ZF-7959, ZF-10427, ZF-10498, ZF2-18)
Consistency and b/c
- Modify parameters of Logger::log($priority, $message, $extras)
- Rename Filter\Message in Filter\StringMatch or Filter\Regex
- Rename Writer subnamespace to Handler (like java, python, ruby, etc)
Proposed Architecture
- Logger: a logging container stores a stack of handlers (subject in observer pattern)
- Record: a logging event is represented by a string, and some metadatas for the context
- Handler: send all logging events outside (to file, to smtp, etc) of the logger (observer in observer pattern)
- Formatter: format and convert log entries for output
- Filter: define a rule in order to exclude log of an event
Thinking
- Do we need a LoggerAggregate?
- Do we need to a Priority class to separate responsability from the Logger?
- Do we need a queue or a stack for writers/handlers?
Labels:
None