WebSphere-无法加载Logmanager "org.apache.logging.log4j.jul.LogManager"[英] WebSphere - Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"

本文是小编为大家收集整理的关于WebSphere-无法加载Logmanager "org.apache.logging.log4j.jul.LogManager"的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我有一个运行WebApp的WebSphere Application Server.我从Eclipse启动服务器.该应用程序中的主要日志记录框架是Log4J2,但是有一些使用Java.util.logging的第三方库.我想将这些日志重定向到log4j2,以便使用我的过滤器,日志格式等.

因此,我尝试添加 log4j >.我在构建路径和部署组件中添加了必要的jar(我仅缺少log4j-jul,因为我已经将其他log4j-jars)添加到了我的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)

我不知道此堆栈跟踪中的大多数类.

问题在于,根据上面链接的log4j文档,我需要在LogManager的第一个调用之前设置LogManager的系统属性痕迹.

有没有办法使罐子在启动的这个阶段知道?

Edit I asked a follow up question 在这里,然后遵循建议使用Log4jBridgeHandler,而不是交换LogManager.

推荐答案

这里的问题是,使用Java.util.logging(Jul)的不仅仅是您的应用程序 - 服务器的核心也是如此,并且通过尝试将Jul重定向到Log4j并使用System属性强制执行(适用于整个JVM),您实际上是在尝试通过Log4J设置将所有登录服务器重定向.服务器消息中的任何内容.log将在您的日志记录中显示.

如果您仍然真的想这样做,最简单的解决方案可能是将log4j-jul jar放入JVM启动类路径中,因此Java System Loader可以看到它(您可能必须使用任何依赖关系做同样的事情和配置文件).同样,您正在覆盖所有服务器级的日志记录,因此我不希望这是支持的配置(如果打开支持案例,他们不想查看您的自定义log4j-formatted Logs for服务器详细信息),但理论上应该具有功能.

本文地址:https://www.itbaoku.cn/post/1575189.html

问题描述

I have an WebSphere Application Server which runs an WebApp. I start the Server from Eclipse. The main logging framework in that application is log4j2, but there are some third party libraries which use java.util.logging. I want to redirect those logs to log4j2 so it uses my filters, log format etc.

Therefore I tried to add the Log4j JDK Logging Adapter. I added the necessary JAR (I lacked only log4j-jul as I already had the other log4j-jars for other purposes) to the Build Path and to the Deployment Assembly and added the line -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager to my jvm.options.

Immediatly after startup I get the following exception:

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)

I don't know most of the classes in this stack trace but to me it looks like the exception is thrown very early, maybe while setting up the JVM, and that the jars packed in my .war file are not yet known.

The problem is that according to the log4j documentation linked above, I need to set the System Property for the LogManager before the first call of the LogManager, which indeed seems to happen in the NotificationBroadcasterSupport from the stack trace.

Is there a way to make the jar known at this stage of startup?

Edit I asked a follow up question here and followed the suggestion there to use the Log4jBridgeHandler instead of swapping out the LogManager.

推荐答案

The problem here is that it's not just your app that uses java.util.logging (JUL) - so does the core of the server, and by attempting to redirect JUL to Log4J and enforcing it with a system property (which applies to the entire JVM), you're essentially attempting to redirect all logging in the server through your Log4J setup. Anything that would be in the server's messages.log is going to show up in your logging instead.

If you still REALLY want to do this, the simplest solution is probably to put the log4j-jul jar into the JVM launch class path, so it's visible to the Java system loader (you may have to do the same with any dependencies and configuration files). Again, you're overriding all of the server-level logging, so I wouldn't expect that this would be a supported configuration (if you open a support case, they're not gonna want to review your custom Log4J-formatted logs for server details), but it should theoretically be functional.