salesforce / rules_spring

Bazel rule for building Spring Boot apps as a deployable jar
BSD 3-Clause "New" or "Revised" License
221 stars 49 forks source link

No log in the console with Spring Boot 2.7.18 #189

Closed luangong closed 5 months ago

luangong commented 5 months ago

I’m building a Spring Boot application with Bazel 7, rules_spring 2.3.1, and Spring Boot 2.7.18. The application runs fine (I can open localhost:8080 in the browser and see the default login page). However, the logs are not shown in the console.

The error message suggests that there is some issue with the version of slf4j-api that was bundled in the executable JAR.

$ java -jar bazel-bin/java/spring-boot2/app.jar
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8.
SLF4J: Ignoring binding found at [jar:file:/path/to/workspace/java/spring-boot2/app.jar!/BOOT-INF/lib/external/rules_jvm_external~6.0~maven~maven_spring_boot2/ch/qos/logback/logback-classic/1.2.12/processed_logback-classic-1.2.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::               (v2.7.18)

[No console output after this line]

I inspected and compared the Bazel-built JAR and the Maven-built JAR and found that there are some different versions of the same JAR—notably, Bazel is using slf4j-api 2.0.0.alpha1 but Maven is using slf4j-api 1.7.36. That might be the cause of the issue (it seems that slf4j-api 2.x doesn’t work with logback-classic 1.2, see Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier). I think this issue might boil down to the difference between how Coursier (used by rules_jvm_external) and Maven resolve artifacts. I didn’t dive deeper though.

Is there any clue how we can fix this?

luangong commented 5 months ago

Sorry. I feel that this issue should be better raised in rules_jvm_external, such as these:

luangong commented 5 months ago

Workaround: override slf4j-api with version 1.7.36 in MODULE.bazel with this:

maven.artifact(
    name = "maven",
    group = "org.slf4j",
    artifact = "slf4j-api",
    version = "1.7.36",
    force_versions = True,
)

or this:

maven.install(
    name = "maven",
    artifacts = [
        # ... Your other artifacts here ...

        # Override slf4j-api with v1.7.36
        "org.slf4j:slf4j-api:1.7.36",
    ],
    version_conflict_policy = "pinned",
    # ... Other attributes ...
)

See Resolving user-specified and transitive dependency version conflicts for more details.