Migrating curity idsvr from log4j2 to logback

Viewed 50

Curity is currently using log4j2 as the default logger. Is there a way to change it to logback.?

Currently I have build a custom Docker image doing the following steps. (base image used curity.azurecr.io/curity/idsvr:6.7.2 )

  1. Replaced the log4j2.xml file with a logback.xml file with logback configuration in the path /opt/idsvr/etc/

  2. Removed existing log4j jar files in the path /opt/idsvr/lib and replaced with logback jar files downloaded from https://logback.qos.ch/download.html

After doing above steps I launched the custom image as a container. But I got the following error messages.

your customer that you accept the terms of the Curity License Agreement.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
idsvr was installed into /opt/idsvr. You can begin using it by starting /opt/idsvr/bin/idsvr
openjdk version "11.0.13" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu11.52+14-SA (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM Zulu11.52+14-SA (build 11.0.13+8-LTS, mixed mode)
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/impl/LogEventFactory
    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
    at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
    at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
    at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
    at se.curity.identityserver.app.LogInitializer.initializeLoggers(LogInitializer.java:54)
    at se.curity.identityserver.app.Bootstrapper.main(Bootstrapper.java:118)
    at se.curity.identityserver.app.Bootstrapper.main(Bootstrapper.java:100)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.core.impl.LogEventFactory
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
    at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
    ... 12 more

Any help would be kindy appreciated. Thanks..

1 Answers

No, replacing Log4j with Logback is not supported. The use of Log4j runs very deep in the product, and cannot be replaced by users. I'd recommend asking another questions about the issue that led you to want to replace the ❤️ of the logging subsystem. Perhaps that has a solution that doesn't require heart surgery.

Related