-
Notifications
You must be signed in to change notification settings - Fork 58
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
Should not shade apache commons logging #714
Comments
HI @OskarKjellin, could you define an appender in your log4j configuration for |
I could, but I want to bridge it to slf4j, not add an appender. Is there a reason why one logging facade (slf4j) is not shaded while another one is (commons-logging)? This mostly seems like an oversight to me, not the wanted behavior |
I checked SDK dependencies, and it neither directly nor transitively depends on I am still not sure if I understand the issue, though. You mention you are bridging |
Hmm, so this issue should be with the JDBC driver? Log4j is not our implementation. The snowflake jdbc driver also includes a shaded version of log4j :( |
Yeah, please open this issue in the JDBC driver repo: https://github.com/snowflakedb/snowflake-jdbc/issues |
Hmm, maybe the jdbc driver doesn't include a shaded version of log4j. Seems to be something else, but still shouldn't shade commons-logging imo |
The current approach of shading all dependencies also means that when the apache http client is shaded, the logging it uses (apache commons logging) also becomes shaded.
When this is shaded it's not possible to use the commons logging to slf4j bridge, meaning that our logs get filled with:
And we don't get any logs from apache http client.
commons-logging:commons-logging
should probably be excluded from shading just asorg.slf4j:slf4j-api
isThe text was updated successfully, but these errors were encountered: