devinrsmith opened a new issue, #10534: URL: https://github.com/apache/iceberg/issues/10534
### Apache Iceberg version 1.5.2 (latest release) ### Query engine None ### Please describe the bug 🐞 I noticed some strange logging issues after depending on `iceberg-aws-bundle`. After a bit of debugging, I found that `iceberg-aws-bundle` includes an unshadowed `org.slf4j.LoggerFactory` (and other `org.slf4j` classes) in the jar: ``` $ jar tf iceberg-gcp-bundle-1.5.2.jar | grep "org/slf4j/LoggerFactory" org/slf4j/LoggerFactory.class ``` I understand the "shading" part of the story, but it does seem a bit odd to also bring in slf4j. Typically, I'd expect `iceberg-aws-bundle` to declare a dependency on `slf4j-api`. Our application depends on, and is bootstrapped assuming slf4j 2.x (for example, we depend on the `ServiceLoader` mechanism for configuration, https://www.slf4j.org/faq.html#changesInVersion200). Normally, if a library we depend on declares a dependency on slf4j-api 1.x this isn't an issue since the public APIs are compatible https://www.slf4j.org/faq.html#compatibility. But, when both 1.x and 2.x are on the same classpath and 1.x "wins", our logging isn't able to initialize properly. Was including `org.slf4j` internal to the bundled jar done on purpose? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
