Feature #94600
Updated by Larry Garfield over 3 years ago
Monolog is a much more robust logger than the existing one in core. There's no sense competing with it, just leveraging it effectively.
This design is driven by a new `typo3conf/logging.yaml` file. Its format looks like this:
<pre><code class="yaml">
monolog:
channels:
default:
handlers: ['@Monolog\Handler\SyslogHandler']
processors: ['@Monolog\Processor\MemoryUsageProcessor']
min_level: info
deprecations:
handlers: ['@Monolog\Handler\SyslogHandler']
processors: ~
min_level: DEBUG
classes:
Foo\Bar:
handlers: [ '@monolog.stream.deprecations' ]
processors: ~
min_level: DEBUG
</code></pre>
An arbitrary number of channels may be predefined, each with its own configuration. Configuration consists of which handlers (by service name) and processors (by service name) are desired. There's also the ability to set a minimum log level that the channel will care about. (I think; that may be on the handler level in Monolog. Still researching, but the above is the intent.)
A service may ask for a logger by name for injection ( @['@monolog.logger.mychannel]@), or just ask for the generic "@logger" service. If it does the latter, the channel to use is derived from the argument name. So a constructor parameter of @$beepLogger@ will get the logger for the "beep" channel. If no beep channel is defined explicitly, it will get the same configuration as the default.
Per-class overrides are I am pretty sure I can also possible, creating work out how to also allow per-class (service?) overrides, such that it's possible to force a virtual one-off custom channel for just that class.
All that I still have not working is setting into a minimum log level for each channel or handler, as specific class from the outside. I'm not sure how useful that Monolog actually has a facility for that. is, but several people have noted they like that feature of the current logger, so if I thought can make it did but I've not located work, I'll include it.