Making the channel handler more useful by showing it on the prod environment #4604
Conversation
| @@ -67,19 +79,21 @@ To do so, just create a new handler and configure it like this: | |||
| // app/config/config.php | |||
There was a problem hiding this comment.
needs file name update too (I couldn't comment on the XML filename, but that should be changed as well)
|
Why did you make it specific for |
|
@wouterj because the standard edition (and my real projects) only have a monolog config key in config_dev and config_prod, so this seems more realistic. But now that you mention it, if you have this specific logging use-case (eg log all security messages to this special file), you will probably want this logged consistently across environments. So now I agree with you - I'll update it :) |
|
|
||
| Each channel corresponds to a logger service (``monolog.logger.XXX``) | ||
| in the container (use the ``container:debug`` command to see a full list) | ||
| and those are injected into different services. |
There was a problem hiding this comment.
however, when defining your services, the way to ask for a given channel is not to use monolog.logger.XXX directly. It is to inject the logger service and set the appropriate tag on your service.
this is necessary because the compiler pass reading these tags is also the place creating these services.
I'm not sure documenting the monolog.logger.XXX naming convention is actually worth it.
There was a problem hiding this comment.
👍 for documenting it as an monolog implementation detail. we should warn to rely on this naming convention
There was a problem hiding this comment.
Actually, I think the specific monolog.logger.XXX service names are guaranteed in a sense, due to this feature: http://symfony.com/doc/current/cookbook/logging/channels_handlers.html#configure-additional-channels-without-tagged-services. And for me, this has always seems a lot more clear - using a tag to change how a logger is injected (in reality, which logger is injected) always seemed obtuse to me. I wonder if we should tell end-users to use the specific services, and leave the tag-usage primarily for third-party code (where you can't create a channel via config).
|
ping @weaverryan |
|
@weaverryan can you please finish/merge this one or put it on the list for saturday? Thanks! |
|
Thanks for the poke Wouter. I actually think all the issues were all taken care of with this, so i merged it in (I did at one last second tiny tweak). |
… the prod environment (weaverryan) This PR was merged into the 2.3 branch. Discussion ---------- Making the channel handler more useful by showing it on the prod environment | Q | A | ------------- | --- | Doc fix? | yes | New docs? | no | Applies to | 2.3+ | Fixed tickets | n/a Hi guys! I realized there were a few practical problems with this: 1) Normally, there is no `monolog` configuration in `config.yml` - so it's odd to show an example there 2) In the `prod` environment (by default, unless you set doctrine's logging explicitly to true), the `doctrine` channel is not logged at all. So, if you tried this example in `config_prod.yml`, it probably wouldn't work. But security is always there. Thanks! P.S. After merging to 2.6, `container:debug` should be changed to `debug:container`. Commits ------- bc79b21 Adding one more note about why we're in config.yml 78323d8 Changing back to config.yml and fixing some code block mistakes thanks to Wouter f9f3c3f Making the channel handler more useful by showing it on the prod environment
Hi guys!
I realized there were a few practical problems with this:
monologconfiguration inconfig.yml- so it's odd to show an example thereprodenvironment (by default, unless you set doctrine's logging explicitly to true), thedoctrinechannel is not logged at all. So, if you tried this example inconfig_prod.yml, it probably wouldn't work. But security is always there.Thanks!
P.S. After merging to 2.6,
container:debugshould be changed todebug:container.