Как перенести свойства Log4j1 с помощью дополнительного регистратора (Authorize.net) в Log4j2 - PullRequest
Новая
       34

Как перенести свойства Log4j1 с помощью дополнительного регистратора (Authorize.net) в Log4j2

0 голосов
/ 22 декабря 2018

У меня есть рабочие настройки Log4j1 и Log4j2, и я интегрировал последний SDK Authorize.net в свое приложение.SDK был создан для использования Log4j1, и я больше не могу контролировать его вывод через файл свойств Log4j2.Первоначально это было сделано в Log4j1 путем добавления следующих инструкций прямо из SDK в мой файл свойств Log4j1: 

log4j.logger.net.authorize.util.HttpClient=FATAL, S
log4j.logger.net.authorize.sim.TransactionTest=FATAL, S

Where S is a console appender

Я пробовал многочисленные конфигурации, самой простой из которых было включение вышеуказанных операторов в файл свойств Log4j2но это не сработало.Я также попытался заменить "log4j" на log4j2 ", но безрезультатно. 

log4j2.logger.net.authorize.util.HttpClient = FATAL, STDOUT
log4j2.logger.net.authorize.sim.TransactionTest = FATAL, STDOUT

Я попытался полностью удалить" log4j ", но это выдает исключение, указывающее на отсутствие атрибута имени для регистратора" net ". 

logger.net.authorize.util.HttpClient = FATAL, STDOUT
logger.net.authorize.sim.TransactionTest = FATAL, STDOUT

Похоже, что игнорируется оставшееся имя регистратора после «net.», Поэтому я добавил следующее утверждение, и исключение ушло, но оно по-прежнему не работает. 

loggers = net.authorize.util.HttpClient

Iтакже пытался контролировать уровень журнала с помощью этих операторов. 

logger.net.authorize.util.HttpClient.name = ANet
logger.net.authorize.util.HttpClient.level = FATAL

Я поставлен в тупик относительно того, как указать дополнительный регистратор в файле свойств Log4j2. Любая помощь будет принята.

Вотмой текущий файл log4j2: 

# Tell the root logger what appenders and level to use

rootLogger.level = DEBUG

rootLogger.appenderRefs = console, rolling
rootLogger.appenderRef.console.ref = STDOUT
rootLogger.appenderRef.rolling.ref = FILE

appenders = console, rolling


##### Authorize.net #####

log4j.logger.net.authorize.util.HttpClient = FATAL, STDOUT
log4j.logger.net.authorize.sim.TransactionTest = FATAL, STDOUT


##### Console Appender #####

appender.console.name = STDOUT
appender.console.type = Console
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss z} %-5p %m%n


##### File Appender #####

appender.rolling.name = FILE
appender.rolling.type = RollingFile
appender.rolling.fileName = mylog.log
appender.rolling.filePattern = mylog.log
appender.rolling.layout.pattern = %d{yyyy-MM-dd HH:mm:ss z} %-5p %m%n
appender.rolling.layout.type = PatternLayout
appender.rolling.policies.type = Policies
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
appender.rolling.policies.size.size = 10MB

1 Ответ

0 голосов
/ 02 января 2019

Оказывается, что Authorize.Net использует commons-logging для абстрагирования реализации logger, предоставляемой log4j2.Commons-logging проходит очень специфический процесс, чтобы определить, какую реализацию логгера использовать, и если она не найдена, используется SimpleLogger JDK.В этом конкретном случае мне не хватало критического jar-файла log4j2, в котором содержался конструктор String, необходимый для ведения журнала общих имен, log4j-jcl.jar.После включения этого в classpath вместе с api и core jar я могу контролировать ведение журнала Authorize.net.

Вот банки, необходимые для log4j2

Вот как commons-logging находит регистратор для использования

...