То есть вы хотите вместо многопоточности просто в асинхронном коде работать? Если так, то я этот кейс в статье не планировал затрагивать. Я думаю можно без проблем найти примеры реализации такого хендлера.
А точно нужно к каждому логгеру (app, app.access и root) прикручивать один и тот же хендлер? Почему бы не оставить его в каком-то из логгеров, который является для приложения корневым и тогда сообщения дублироваться не будут. Сообщение будет просто проходить весь путь до корневого логгера и фильтроваться при необходимости, а затем в корневом будет записано как и куда надо.
Я бы рекомендовал просто нарисовать общую схему конкретно для вашего приложения, по типу того, что я привожу в статье. Тогда возможно станет понятнее каким образом лучше организовать все логгеры и хендлеры.
Не совсем понял кейс. Что подразумевается под "отдельные/вложенные пакеты"? Если у нас есть логгер app и дочерние от него логгеры (для вложенных модулей?), включая дочерний от app логгер app.access, то уровни присвоятся соответственно - на app будет debug, на app.access будет warning, а на root будет info. Что в итоге запишется в журнал, а что будет отброшено, зависит от того, как вы разместите хендлеры по этим логгерам. Например, если хендлеры будут только в root logger, то debug сообщения от app и дочерних логгеров никуда не запишутся (от app.access они не дойдут до рутового логгера изначально, потому что у самого логгера app.access выставлен уровень WARN)
То есть вы хотите вместо многопоточности просто в асинхронном коде работать? Если так, то я этот кейс в статье не планировал затрагивать. Я думаю можно без проблем найти примеры реализации такого хендлера.
(del)
Предложенный в статье QueueHandler фактически это и делает.
Что конкретно вы имеете ввиду?
А точно нужно к каждому логгеру (app, app.access и root) прикручивать один и тот же хендлер? Почему бы не оставить его в каком-то из логгеров, который является для приложения корневым и тогда сообщения дублироваться не будут. Сообщение будет просто проходить весь путь до корневого логгера и фильтроваться при необходимости, а затем в корневом будет записано как и куда надо.
Я бы рекомендовал просто нарисовать общую схему конкретно для вашего приложения, по типу того, что я привожу в статье. Тогда возможно станет понятнее каким образом лучше организовать все логгеры и хендлеры.
Не совсем понял кейс. Что подразумевается под "отдельные/вложенные пакеты"?
Если у нас есть логгер app и дочерние от него логгеры (для вложенных модулей?), включая дочерний от app логгер app.access, то уровни присвоятся соответственно - на app будет debug, на app.access будет warning, а на root будет info. Что в итоге запишется в журнал, а что будет отброшено, зависит от того, как вы разместите хендлеры по этим логгерам. Например, если хендлеры будут только в root logger, то debug сообщения от app и дочерних логгеров никуда не запишутся (от app.access они не дойдут до рутового логгера изначально, потому что у самого логгера app.access выставлен уровень WARN)
У вас изначально в структуре проекта есть конфиг для MySQL в файле:
./app/volumes/etc/mysql/config-file.cnf
Однако в контейнер вы уже монтируете:
./volumes/mysql/conf.d:/etc/mysql/conf.d:ro
Я что-то недопонял или опечатка?