Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

org.slf4j:slf4j-nop SLF4J binding imposed in mil.nga.geopackage:geopackage #62

Open
phanecak-maptiler opened this issue Apr 26, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@phanecak-maptiler
Copy link

phanecak-maptiler commented Apr 26, 2024

Version Information:

  • GeoPackage Java Version: 6.6.5
  • GeoPackage Java Source: Mvn Central
  • IDE Name & Version: Java 21
  • Maven Version: 3.9.1
  • Java Version: openjdk version "21.0.2" 2024-01-16
  • Platform & OS: Linux
  • Other Relevant Libraries: log4j-slf4j2-impl 2.23.1 used in Planetiler project (https://github.com/onthegomap/planetiler)

Expected Results:

log4j-slf4j2-impl to be used as SLF4J binding without warnings

Observed Results:

Warning being printed by Planetiler, see "Output" bellow.

Output:

SLF4J(W): Class path contains multiple SLF4J providers.
SLF4J(W): Found provider [org.apache.logging.slf4j.SLF4JServiceProvider@49097b5d]
SLF4J(W): Found provider [org.slf4j.nop.NOPServiceProvider@6e2c634b]
SLF4J(W): See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J(I): Actual provider is of type [org.apache.logging.slf4j.SLF4JServiceProvider@49097b5d]

Steps to Reproduce:

  1. Compile current Planetiler/main branch
  2. Run it

Relevant Code:

import mil.nga.geopackage.GeoPackage;
...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private static final Logger LOGGER = LoggerFactory.getLogger(Generate.class);

See for example https://github.com/onthegomap/planetiler/blob/main/planetiler-core/src/main/java/com/onthegomap/planetiler/reader/GeoPackageReader.java

Test Files:

no

Additional Information:

SLF4J suggests:

Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant