Как изменить канал Monolog для некоторых контроллеров Symfony 3.4 или 4+

Я хочу сменить канал Monolog. Мои объявления работают с некоторыми классами, но никогда с контроллерами.

Вот мое новое объявление канала админ:

#config/packages/dev/monolog.yaml
monolog:
    handlers:
        admin:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%-admin.log"
            level: debug
            channels: ["admin"]

Я успешно использую его с моим Authenticator, добавляя тег:

#config/services.yaml
# The form guard authenticator for the admin access
app.security.admin_authenticator:
    class: App\Security\AdminAuthenticator
    autowire: true
    tags:
        - { name: monolog.logger, channel: admin}

Последняя строка файла services.yaml выполняет свою работу, мой Authenticator больше не регистрируется в канале приложение, он регистрируется в канале админ.

Теперь я хочу использовать этот канал с контроллерами в подкаталоге Admin, поэтому я добавляю аналогичный тег в свое объявление:

#config/services.yaml
App\Controller\Admin\:
    resource: '../src/Controller/Admin'
    tags:
        - 'controller.service_arguments'
        - { name: monolog.logger, channel: admin}

Но вроде нет никакого воздействия. Я все еще вхожу в канал приложение. (Я сделал некоторую проверку, например, обновил кеш). Я не нахожу своей ошибки.

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Symfony Station Communiqué - 17 февраля 2023 г
Symfony Station Communiqué - 17 февраля 2023 г
Это коммюнике первоначально появилось на Symfony Station , вашем источнике передовых новостей Symfony, PHP и кибербезопасности.
Управление ответами api для исключений на Symfony с помощью KernelEvents
Управление ответами api для исключений на Symfony с помощью KernelEvents
Много раз при создании api нам нужно возвращать клиентам разные ответы в зависимости от возникшего исключения.
5
0
1 742
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Не могу разобраться с методом тега. Однако вы можете определить свой канал монолога как аргумент конструктора вашего контроллера:

# monolog package configuration
monolog:
    channels: [ 'admin' ]
    handlers:
        admin:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%-admin.log"
            level: debug
            channels: ["admin"]

Конфигурация автоматической проводки:

#config/services.yaml
App\Controller\Admin\:
    resource: '../src/Controller/Admin'
    arguments:
        $logger: '@monolog.logger.admin'
    tags:
        - 'controller.service_arguments'

И в ваших контроллерах

/**
 * SecurityController constructor.
 * @param LoggerInterface $logger
 */
public function __construct(LoggerInterface $logger)
{
    $this->logger = $logger;
}

Спасибо за вашу помощь. Завтра утром протестирую!

Alexandre Tranchant 20.03.2018 19:50

Да, это работает. Но я думаю, что добавлять конструктор в контроллер - не лучшая практика. Итак, я реализую LoggerAwareInterface и вызываю метод setLogger в services.yaml. Решение, предложенное mrbm, работает с тегом.

Alexandre Tranchant 22.03.2018 21:35
Ответ принят как подходящий

Я не пробовал это, но, скорее всего, потому, что ваш контроллер не поддерживает LoggerAwareInterface, поэтому тег регистратора не влияет.

Проверьте, какой интерфейс реализует AdminAuthenticator (чтобы увидеть, как настраивается регистратор), затем проделайте то же самое с контроллером, который должен работать.

#services.yaml
App\Controller\Admin\:
    resource: '../src/Controller/Admin'
    calls:
        - [ setLogger, [ '@logger' ] ]
    tags:
        - 'controller.service_arguments'
        - { name: monolog.logger, channel: admin}

Спасибо за вашу помощь. Завтра утром протестирую!

Alexandre Tranchant 20.03.2018 19:50

Даже если я реализую LoggerAwareInterface, тег регистратора не повлияет. Поэтому я буду использовать решение @MatMouth. Но я не буду использовать конструктор. Я вызову setLogger и реализую LoggerAwareInterface с объявлением в services.yaml.

Alexandre Tranchant 22.03.2018 20:57

Тег будет считан регистратором в любом случае, при реализации LoggerAwareInterface вам, возможно, придется выполнить подключение вручную, например: добавление - [ setLogger, [ '@logger' ] ] в calls: непосредственно перед tags

mrbm 22.03.2018 21:17

Другие вопросы по теме