Ведение журнала в служебных классах - PullRequest
Новая
       32

Ведение журнала в служебных классах

3 голосов
/ 03 марта 2010

Я хочу использовать протоколирование в нескольких служебных классах, e. г. DBI. Как лучше всего делать это с Log :: Log4perl?

Я думаю, что это нормально для подкласса DBI (скажем, MyDBI) и переопределить некоторые методы там, чтобы заставить их делать регистрацию. Но есть проблема с категориями. Если вы создаете регистратор с 

Log::Log4perl->get_logger(ref $self || $self)

тогда все записи журнала принадлежат MyDBI, и их будет сложно отфильтровать. Поэтому, мне кажется, лучше передать регистратор в MyDBI из вызывающего модуля (скажем, MyModule), чтобы эта категория была семантически правильной. Первый вопрос, нормально ли это вообще? Я имею в виду, есть ли скрытые подводные камни в отношении такого подхода?

Второй вопрос, как передать регистратор на MyDBI? У меня есть идея объявить глобальную переменную, т.е. г. $MyDBI::logger и установить в методе вызова: 

local $MyDBI::logger = Log::Log4perl->get_logger(ref $self || $self);

Существует традиционная неприязнь к глобальным переменным. Вы можете придумать лучший способ?

РЕДАКТИРОВАТЬ: Конечно, лучший код не код. caller будет достаточно, если принять во внимание наследование.

Третий вопрос, возможно ли войти в обе категории, MyDBI и MyModule, с помощью Log :: Log4perl, если они иерархически не связаны?

1 Ответ

2 голосов
/ 09 марта 2010

Я бы настоятельно рекомендовал вам регистрироваться независимо от вызывающего абонента в отдельном регистраторе либо для каждой функции, либо для каждого модуля, чтобы вы могли запускать свой модуль независимо от log4perl, используемого в вашем вызывающем устройстве. Каждый модуль создаст свой собственный регистратор с Log::Log4perl->get_logger("module name").
. Если вызывающая сторона не создает никакого приложения, программа просто ничего не регистрирует, и log4perl в модулях будет игнорироваться с функциональной точки зрения.
Log4Perl реализует одноэлементный шаблон для создания регистратора, который похож на глобальную переменную.
Ваша регистрация должна быть как можно более детальной, и, как правило, я регистрирую отладку любого входного параметра и любого результата функции / метода. Если это действительно необходимо, вы также можете использовать трассировку стека, чтобы выяснить, кто вызвал ошибку. Добавление его в параметры просто добавляет дополнительную сложность.

Следующие рецепты могут дать вам больше идей о гибкости на стороне конфигурации log4perl. Рецепты Log4Perl Для меня вся идея - оставить код без изменений и изменить конфигурацию журналирования в зависимости от моего фактического требования к ведению журнала / отслеживанию ошибок (которые могут измениться в будущем). Сохранение кода без изменений, если возможно, еще более важно для модулей, так как вы хотите избежать тестирования всех вызывающих программ.

Чтобы ответить на ваши вопросы вкратце. 1.) Каждый модуль должен иметь свой собственный регистратор 2.) При этом не добавляйте регистраторы в интерфейс 3.) Log4Perl будет входить на всех уровнях в зависимости от конфигурации вашего приложения. Таким образом, вы контролируете то, что увидите, но не видите - обычно уровень INFO, а определенные модули могут быть отлажены. В плохих случаях компоновка Pattern позволит вам добавить трассировку стека в журнал исключительно с помощью конфигурации.

...