#126 Inject a LoggerInterface for log->alert #130
Conversation
The alert will also append a JSON copy of the check(s) that failed
acd209c to
86d7087
Compare
| { | ||
| $this->runnerManager = $runnerManager; | ||
| $this->pathHelper = $pathHelper; | ||
| $this->template = $template; | ||
| if ($log === null) { | ||
| $log = new NullLogger(); |
There was a problem hiding this comment.
I would rather move this "logic" to the DI layer
There was a problem hiding this comment.
OK, I'll remove the NullLogger, and require a valid logger to be injected. Users can can replace it with another Logger, Null, or otherwise.
| @@ -17,6 +17,7 @@ | |||
| <argument type="service" id="liip_monitor.helper.runner_manager" /> | |||
| <argument type="service" id="liip_monitor.helper" /> | |||
| <argument>%liip_monitor.view_template%</argument> | |||
| <argument type="service" id="logger" on-invalid="ignore" /> | |||
There was a problem hiding this comment.
I guess this needs to be mandatory .. we just need to ensure we have a logger to inject ..
I am not sure if the core logger service defaults to NullLogger if no logging is enabled .. if not we would need to create our own service which we optionally alias to the core logger via a compiler pass if the logger service is defined
There was a problem hiding this comment.
It would be fine as mandatory - not having a logger service is a little silly anyhow.
I have tested the symfony-demo app (v2.7.6) with all monolog configs removed, and you still get a valid LoggerInterface (a Symfony\Bridge\Monolog\Logger) - but it has no handlers and so will just try to send to STDERR.
There was a problem hiding this comment.
I fear it means we then require that the MonologBundle is active ..
@stof can you confirm this? what is the current best practice here? I seem to remember that we are phasing out if (null !== $this->logger) { type code in core .. and afaik also making NullLogger fallback instances ..
There was a problem hiding this comment.
Core Symfony appears to only use a NullLogger in testing. Other logging happens within a if (null !== $this->logger) check, 'for performance reasons'.
I think that any tiny reduction of speed within the bundle would be more than offset by the clarity of code with a new NullLogger() in the constructor - but I'd be happy to wrap the logging calls I've written in conditionals anyway if that is the general consensus.
That would also leave the controller.xml as it was originally - allowing the logger to be able to be optional, and so fail-safe if there was no such service (in Yaml, it would be "?@logger"), and so it would default to null from the constructor parameter.
|
As it stands now, you are required to be using the controller shipped with this bundle to have logging enabled. What about having the logging logic in a |
|
Is this PR likely to be merged anytime soon? Is there anything I can do to help? |
|
as the discussion is quite stale .. no there were no immediate plans. do you need this feature? what do you think about @kbond's suggestion? |
|
I like the suggestion of having logs enabled via config. |
|
sounds good to me and would be inline with what @kbond was suggesting. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This pull request has been automatically closed. Feel free to re-create if it is still relevant. |
The alert will also append a JSON copy of the check(s) that failed.
If a logger is not given, will default to a NullLogger.