移除Log4j改用Logback：Corda节点依赖冲突问题排查

Short Answer #

Yes, but you need to account for Corda's node runtime classpath priority—Corda 3.x nodes ship with Log4j SLF4J bindings baked into their core Capsule distribution, which overrides your cordapp's Logback dependencies unless you explicitly adjust the node's startup configuration.

Root Cause of Your Issue #

The logs show SLF4J is picking up log4j-slf4j-impl from the Corda node's core jar (net.corda.node.Corda_3.1-corda.jar), not your cordapps. Your Gradle exclude rules only affect your project's dependencies, but the node's own runtime classpath takes precedence when loading SLF4J bindings. Tests work because Gradle controls their classpath entirely, excluding Log4j and prioritizing Logback.

Step-by-Step Solution #

1. Verify Your Cordapp Dependency Setup

First, double-check your Gradle config to ensure you've fully excluded Log4j and included Logback correctly:

configurations.all {
    exclude group: 'org.apache.logging.log4j', module: 'log4j-api'
    exclude group: 'org.apache.logging.log4j', module: 'log4j-core'
    exclude group: 'org.apache.logging.log4j', module: 'log4j-slf4j-impl'
    exclude group: 'org.slf4j', module: 'jcl-over-slf4j'
    exclude group: 'org.apache.logging.log4j', module: 'log4j-web'
}

dependencies {
    implementation 'ch.qos.logback:logback-classic:1.2.3' // Includes logback-core and slf4j-api
}

Ensure all your cordapps (trade-input-cordapp, common, etc.) use this config to avoid bringing Log4j back in.

2. Override the Node's Classpath Priority

To force SLF4J to use Logback instead of the node's built-in Log4j bindings, you need to prepend Logback's jars to the node's classpath on startup:

• Locate the Logback jars from your Gradle cache (or download them directly):
  • logback-classic-1.2.3.jar
  • logback-core-1.2.3.jar
  • slf4j-api-1.7.25.jar (matches Logback 1.2.3's SLF4J version)
• Modify the node's startup command to include these jars first in the classpath:

java -cp "/path/to/logback-classic-1.2.3.jar:/path/to/logback-core-1.2.3.jar:/path/to/slf4j-api-1.7.25.jar:/path/to/net.corda.node.Corda_3.1-corda.jar" net.corda.node.Corda

This ensures SLF4J loads Logback's StaticLoggerBinder before the node's Log4j version.

3. Add a Logback Configuration File

Create a logback.xml file in your node's root directory (e.g., build/nodes/party/logback.xml) to define your logging rules. Example config matching Corda's default behavior:

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logs/node.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>logs/node.%d{yyyy-MM-dd}.log</fileNamePattern>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="info">
        <appender-ref ref="FILE"/>
    </root>
</configuration>

Tell the node to use this config by adding a JVM parameter to the startup command:

java -Dslf4j.configurationFile=./logback.xml -cp "/path/to/logback-jars:/path/to/corda-node.jar" net.corda.node.Corda

4. Optional: Remove Log4j Bindings from the Node Jar

If you want a more permanent fix, you can unpack the Corda node jar, delete the log4j-slf4j-impl-2.9.1.jar from its internal lib directory, then repack the jar. This avoids needing to adjust the classpath every time you start the node, but note that this modifies the official Corda distribution and may break future updates.

Key Notes #

• Ensure none of your Corda node code (or Corda's own core code) directly uses Log4j's API (org.apache.logging.log4j.Logger). All logging should use SLF4J's API (org.slf4j.Logger) to work with Logback.
• Test the node startup thoroughly to confirm no Log4j-related errors appear, and logs are written according to your Logback config.

内容的提问来源于stack exchange，提问作者Dan Newton