(10-18-2019, 01:39 PM)kilishan Wrote: Not sure exactly what you mean. It already supports multiple loggers that can be [set up]
to log individual log levels. What tweaks were you thinking?
Primarily moving the handler configs into distinct classes and changing the
$handlers property of
Config\Logger\Logger to simply be the list of handlers that are executed, e.g.
PHP Code:
public $handlers = [
'CodeIgniter\Log\Handlers\FileHandler' => 'Config\Logger\Handlers\FileHandler',
// The ChromeLoggerHandler requires the use of the Chrome web browser
// and the ChromeLogger extension. Uncomment the next line to use it.
'CodeIgniter\Log\Handlers\ChromeLoggerHandler' => 'Config\Logger\Handlers\ChromeLoggerHandler'
];
The key is obvious (I think) and the value is the config file for the handler class. There's probably a better way to supply the
handler config and I would really like some feedback on the above.
A question: What's the usefulness in having
CodeIgniter\Log\Logger::log() return a boolean? I don't see the return as a problem, but I also don't see the point. I cannot find where the return is used anywhere in the core or the App namespace. I was thinking of changing the return to
void.
I don't think
CodeIgniter\Log\Logger will require much refactoring. However, I was wondering if it might be easier to instantiate the handlers in the constructor. Then when it came time to run
Logger::log() all you have to do is iterate through the list of cached handler instances calling
handle() on each in turn.
Oh, and I would not stop processing the handler list if one of them returns
false.
I started exploring the Logger to see about handling
Logger Path Duplicated #2286 and now I'm in up to my elbows.