Потенциальная альтернатива настройке свойства additivity
заключается в проверке ваших регистраторов от наиболее специфических до наиболее общих. В следующем примере мы ожидаем увидеть двойное ведение журнала в консоли для любых событий журнала, происходящих в foo.bar.LoggingExampleClass. Было бы безопасно удалить дополнительный Console appender из регистратора foo.bar.LoggingExampleClass, поскольку он уже покрыт корневым регистратором.
<Logger name="foo.bar.LoggingExampleClass" level="DEBUG">
<AppenderRef ref="Console" /> <!-- THIS APPENDER COULD BE REMOVED -->
<AppenderRef ref="FooBarPackageLogging" />
</Logger>
<Root level="WARN">
<AppenderRef ref="Console" />
<AppenderRef ref="MainLogFile" />
</Root>
Есть компромиссы как с подходом корректировки аддитивности, так и с подходом корректировки аппендера. Отключение аддитивности может непреднамеренно помешать использованию желаемого приложения-регистратора общего уровня. В вышеприведенном примере установка свойства additivity="false"
для регистратора foo.bar.LoggingExampleClass будет означать, что событие регистрации не будет добавлено к файлу MainLogFile, указанному в корневом журнале.
С другой стороны, полагаться на родительских дополнений может быть проблематично, если их родительские дополнения будут изменены без изучения влияния на более детализированные регистраторы. Например, предположим, что существует требование, чтобы события ведения журнала foo.bar.LoggingExampleClass записывались в консоль. В настоящее время они находятся в приведенном выше примере конфигурации из-за аддитивности, даже если удалено приложение Console Logger foo.bar.LoggingExampleClass Logger. Однако, если приложение Console также было удалено из корневого регистратора без каких-либо дополнительных настроек, требование больше не будет выполнено.