WebSphere - не удалось загрузить Logmanager "org.apache.logging.log4j.jul.LogManager" - PullRequest
Новая
       75

WebSphere - не удалось загрузить Logmanager "org.apache.logging.log4j.jul.LogManager"

0 голосов
/ 24 апреля 2019

У меня есть WebSphere Application Server, на котором работает WebApp.Я запускаю Сервер из Eclipse.Основной каркас журналирования в этом приложении - log4j2, но есть некоторые сторонние библиотеки, которые используют java.util.logging.Я хочу перенаправить эти журналы в log4j2, чтобы он использовал мои фильтры, формат журналов и т. Д.

Поэтому я попытался добавить Log4j JDK Logging Adapter .Я добавил необходимый JAR (мне не хватало только log4j-jul, поскольку у меня уже были другие log4j-jar для других целей) в путь сборки и в сборку развертывания и добавил строку -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager в мой jvm.options.

Сразу после запуска я получаю следующее исключение: 

Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
    at java.net.URLClassLoader.findClass(URLClassLoader.java:609)
    at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:850)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:829)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:329)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:809)
    at java.util.logging.LogManager$1.run(LogManager.java:206)
    at java.util.logging.LogManager$1.run(LogManager.java:192)
    at java.security.AccessController.doPrivileged(AccessController.java:594)
    at java.util.logging.LogManager.<clinit>(LogManager.java:192)
    at java.util.logging.Logger.demandLogger(Logger.java:459)
    at java.util.logging.Logger.getLogger(Logger.java:513)
    at com.sun.jmx.remote.util.ClassLogger.<init>(ClassLogger.java:67)
    at javax.management.NotificationBroadcasterSupport.<clinit>(NotificationBroadcasterSupport.java:376)
    at com.ibm.lang.management.OperatingSystemMXBeanImpl.<init>(OperatingSystemMXBeanImpl.java:38)
    at com.ibm.lang.management.ExtendedOperatingSystem.<clinit>(ExtendedOperatingSystem.java:23)
    at com.ibm.lang.management.RuntimeMXBeanImpl.<clinit>(RuntimeMXBeanImpl.java:29)
    at com.ibm.lang.management.ManagementUtils.getRuntimeBean(ManagementUtils.java:402)
    at java.lang.management.ManagementFactory.getRuntimeMXBean(ManagementFactory.java:393)
    at com.ibm.ws.logging.internal.impl.LogProviderConfigImpl.getLogHeader(LogProviderConfigImpl.java:259)
    at com.ibm.ws.logging.internal.impl.LogProviderConfigImpl.<init>(LogProviderConfigImpl.java:177)
    at com.ibm.ws.logging.internal.impl.LogProviderImpl.configure(LogProviderImpl.java:31)
    at com.ibm.ws.kernel.launch.internal.LauncherDelegateImpl.getLogProviderImpl(LauncherDelegateImpl.java:185)
    at com.ibm.ws.kernel.launch.internal.LauncherDelegateImpl.launchFramework(LauncherDelegateImpl.java:91)
    at com.ibm.ws.kernel.boot.internal.KernelBootstrap.go(KernelBootstrap.java:212)
    at com.ibm.ws.kernel.boot.Launcher.handleActions(Launcher.java:246)
    at com.ibm.ws.kernel.boot.Launcher.createPlatform(Launcher.java:121)
    at com.ibm.ws.kernel.boot.cmdline.EnvCheck.main(EnvCheck.java:59)
    at com.ibm.ws.kernel.boot.cmdline.EnvCheck.main(EnvCheck.java:35)

Я не знаю большинство классов в этой трассировке стека, но мне кажется, что исключение выдается очень рано, возможно при установкедо JVM, и что банки, упакованные в мой файл .war, еще не известны.

Проблема заключается в том, что в соответствии с документацией log4j, указанной выше, мне нужно установить системное свойство для LogManager перед первым вызовом LogManager, что, по-видимому, действительно происходит в NotificationBroadcasterSupportот трассировки стека.

Есть ли способ сделать банку известной на этом этапе запуска?

Редактировать Я задал дополнительный вопрос здесь и последовал запредложение использовать Log4jBridgeHandler вместо замены LogManager.

1 Ответ

2 голосов
/ 24 апреля 2019

Проблема здесь в том, что не только ваше приложение использует java.util.logging (JUL) - так же, как и ядро ​​сервера, и пытается перенаправить JUL в Log4J и принудительно применять его с помощью системного свойства (которое применяетсяко всей JVM), вы, по сути, пытаетесь перенаправить всю регистрацию на сервере через настройку Log4J.Все, что будет в файле messages.log сервера, будет отображаться в вашем журнале регистрации.

Если вы все еще ДЕЙСТВИТЕЛЬНО хотите это сделать, самое простое решение, вероятно, состоит в том, чтобы поместить jar log4j-jul в JVMЗапустите путь к классу, чтобы он был виден загрузчику системы Java (возможно, вам придется делать то же самое с любыми зависимостями и файлами конфигурации).Опять же, вы переопределяете все журналы на уровне сервера, поэтому я не ожидаю, что это будет поддерживаемая конфигурация (если вы откроете службу поддержки, они не захотят просматривать ваши пользовательские журналы в формате Log4J длясведения о сервере), но теоретически он должен быть функциональным.

...