Как отдельно регистрировать журналы, специфичные для сервера JBoss, с помощью JBoss Logging и журналы, специфичные для приложений, с помощью log4j?

Мы работаем над переносом нашего приложения с WebSphere на JBoss EAP 6.4. Я читал в Интернете, что, начиная с JBoss EAP 6.x, JBoss использует свою собственную структуру ведения журналов под названием JBoss Logging вместо log4j ранее.

У нас уже есть файл log4j.properties для журналов конкретных приложений, которые хранят журналы в отдельных файлах в соответствии с уровнем журнала (log-error.log, log-info.log, ...), но на самом деле они также регистрируются в консоли и в файле server.log.

С одной стороны, мы хотели бы, чтобы журналы приложений записывались только в наш существующий файл конфигурации log4j.properties, но также запрещали бы их регистрацию в server.log и консоли.

С другой стороны, мы хотели бы, чтобы журналы для конкретных серверов регистрировались с помощью среды JBoss Logging, то есть в файле server.log и в консоли.

Подводя итог, мы хотим перейти от:

application logs + server logs => server.log/console + separate file logs

К этому :

application logs => seperate file logs
server logs => server.log/console

Кто-нибудь знает, как этого добиться? Кто-нибудь уже настроил сервер JBoss подобным образом?

Спасибо,

С Уважением.


java slf4j jboss jboss-logging jboss-eap-6
person Fabien LH    schedule 04.08.2017    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Не понимаю, почему, но log4j также регистрируется в стандартном выводе, поэтому JBoss Logging перехватывает эти журналы и снова добавляет их в консоль JBoss и server.log следующим образом:

2017-08-08 15:14:20,304 INFO [stdout] <<My log4j log message>>.

На данный момент мне удалось предотвратить это, добавив этот код в файл standalone.xml:

<logger category="stdout" use-parent-handlers="false">
    <level name="OFF"/>
</logger>

Разве это не плохая практика?

Спасибо,

person Fabien LH    schedule 08.08.2017
comment
Если что-то записывает в System.out, это не будет зарегистрировано. Это будет единственная проблема. - person James R. Perkins; 08.08.2017
comment
Не думаю, что это будет проблемой, использование System.out в нашем приложении не рекомендуется, но в случае, как вы думаете, я могу объявить регистратор stdout в моем файле log4j.properties? Что-то вроде log4j.logger.stdout = INFO, outAppender? Просто чтобы убедиться, что мы не потеряем журналы, и найти вызовы System.out, чтобы удалить их. - person Fabien LH; 09.08.2017
comment
Возможно нет. JBoss EAP заменяет System.setOut() и System.setErr() потоками, поддерживаемыми регистратором. Это на случай, если кто-то запишет в один из этих потоков, а консольный поток будет отброшен. - person James R. Perkins; 09.08.2017

arrow_upward
1
arrow_downward

Если вы включите файл log4j.proeprties в WAR/WEB-INF/classes или EAR/META-INF, он должен просто работать. Если вы видите ведение журнала для конкретного приложения во всех местах, я предполагаю, что у вас есть консольный аппендер, настроенный в вашем файле log4j.properties.

person James R. Perkins    schedule 04.08.2017
comment
После удаления консольного приложения в моем файле свойств log4j он все еще не работает. Любые идеи ? - person Fabien LH; 07.08.2017
comment
Это развертывание WAR или EAR? Используете ли вы log4j в качестве основы ведения журналов? - person James R. Perkins; 07.08.2017
comment
Это развертывание EAR. Да, мы. Мы используем log4j с самодельным уровнем ведения журнала, который вызывает методы ведения журнала log4j с дополнительной агрегацией информации журнала. - person Fabien LH; 08.08.2017
comment
Не понимаю, почему, но log4j также регистрируется в стандартном выводе, поэтому JBoss Logging перехватывает эти журналы и обрабатывает их снова, добавляя их в консоль JBoss и server.log следующим образом: INFO [stdout] <<My log4j log message>> - person Fabien LH; 08.08.2017
comment
Поэтому, если вы видите журналы [stdout] и используете ConsoleApppender, похоже, что JBoss EAP видит вашу конфигурацию ведения журналов. JBoss EAP оборачивает stdout и stderr в регистраторы. - person James R. Perkins; 08.08.2017
comment
Пожалуйста, смотрите мой ответ. - person Fabien LH; 08.08.2017

arrow_upward
1
arrow_downward

Я потратил несколько дней, чтобы понять это, и я думаю, что у меня есть что-то, что работает. Я использую EAP 6.4.

Во-первых, упомянутое выше решение о добавлении кода в standalone.xml делает вывод моего решения, описанного ниже, более удобным для чтения в консоли. Если вы не сделаете этого шага, вы получите несколько дополнительных переводов строк в консоли.

Я создал файл log4j.xml, но НЕ назвал его log4j.xml. Для моих двух приложений я назвал его servicelog4j.xml. Это означает, что JBoss его не найдет.

Затем, когда я создаю регистратор log4j, я делаю следующее (это статический метод для моего класса с именем Log4jLogger):

public static Logger getLogger(Class aClass) {
    ClassLoader classLoader = Log4jLogger.class.getClassLoader();
    InputStream log4JStream = classLoader.getResourceAsStream("servicelog4j.xml");
    if (log4JStream != null) {
        new DOMConfigurator().doConfigure(log4JStream, LogManager.getLoggerRepository());
    }

    Logger log = Logger.getLogger(aClass);
    return log;
}

Теперь файл servicelog4j.xml находится в папке ресурсов моего проекта Eclipse, поэтому при развертывании приложения он будет скопирован в WEB-INF/classes/servicelog4j.xml.

Содержимое этого файла представляет собой стандартный файл log4j. У меня есть стандартное приложение для файлов и консольное приложение. Файловые приложения для каждого приложения указывают на разные файлы.

Чтобы код отладки только для моих классов отображался в консоли (и в файле), я помещаю в servicelog4j.xml следующее (поскольку весь мой код находится в пакете com.mycompany.mypackage):

  <logger name="com.mycompany.mypackage">
      <level value="debug" />
      <appender-ref ref="CONSOLE" />
  </logger>
  <root>
      <priority value ="info" />
      <appender-ref ref="FILE" />
  </root>

С приведенной выше конфигурацией я получаю все сообщения в консоли Eclipse, а также в файле. Если я просто удалю раздел <logger>, то отладочные сообщения никуда не денутся, а это то, что мне нужно в продакшене.

person Irv    schedule 03.07.2018