If memory serves me correctly, no, you can't shade+relocate logging classes. The way that log4j/slf4j "find" the logging classes breaks down when you do this.
However, if I'm wrong as I very well could be, shading could be an effective solution to this. Alternatively, we could generate an artifact which does not provide logging classes; however, I think we'd need to consider the burden in creating, maintaining, and distributing an extra jar just to remove an slf4j warning (unless Liang's problem extends beyond that -- not sure) On Sat, Dec 22, 2018 at 10:39 PM Miles Spielberg <mi...@box.com> wrote: > > Could the classes be shaded into a different package to prevent conflicts > with libraries included by applications? HBase client has been doing this for > a while: > https://www.i-programmer.info/news/197-data-mining/11427-hbase-14-with-new-shaded-client.html > > Sent from my iPhone > > On Dec 22, 2018, at 9:25 AM, Josh Elser <els...@apache.org> wrote: > > This is as expected. JDBC expects that a database driver provide all of its > dependencies in a single jar file. > > On Mon, Dec 17, 2018 at 4:39 PM Liang Zhao <lz...@casa-systems.com> wrote: >> >> Hi, >> >> >> >> We found slf4j class files in your phoenix-5.0.0-HBase-2.0-client.jar, which >> caused multiple binding of slf4j as the Spring Boot in our project uses a >> different version. We can work around this, but conventionally, a jar file >> only need to name its transitive dependencies, instead of including them. >> >> >> >> The same problem is seen in phoenix-4.14.0-HBase-1.4-client.jar. >> >> >> >> Thanks >> >> >> >> Liang >> >> >> >> <image001.png> >> >>
