The shaded client jar does not play well with SPI and loading alternative logging backends. Chatting with @rjernst and @jasontedor about issue #26318 and possible solutions, we came up with a few possibilities and then some questions to answer.

The most immediate solution, given the state of the shaded jar today, is to make the user shade the jar they want to use. If they shade o.a.logging to o.e.c.c.logging , this should work. This does not make it easy for consumers of this jar who want to use a different backend.

Given that the "solution" is not very user friendly, the next question was if we should even shade commons-logging. commons-logging is probably more widely used than commons-http. This is somewhat speculative, but its likely logging is in more applications already than the http client. So this could be the biggest offender for integrating the rest client into an existing application (which is why we shaded it). This is still an open question as to if we shade this or not.

If we do not shade logging, then should we even shade http?

The need for this was necessitated by the fact that we expose commons-http in the low level rest client. Should we expose this? Why are we using commons-http instead of say, netty? If we decide we might use netty or something besides commons-http in the future, should we just revert the shading? Regardless there will be a breaking change if we decide to implement this change, and given that, does it make sense to even shade currently? Does it make the life of enough people simpler that it is worth punting on the logging issue and telling people they need to shade their backend too?