Remove JAXRS HttpClient instrumentations

[trask]

The Jersey, CXF and RESTEasy http client instrumentations are producing duplicate CLIENT spans currently, because they use HttpURLConnection by default (which looks pluggable at least in some cases).

(btw another reason for #5261 (comment))

The standard solution of course is to make the client spans created by these instrumentations "active" before they delegate to underlying http client library.

This is surprisingly difficult because of the layer at which this instrumentation is written.

The instrumentation is written as a JAX-RS ClientRequestFilter and ClientResponseFilter, I suspect in order to get access to the underlying HTTP url and response code, which aren't readily available at the JAXRS layer.

But this makes things hard already because the ClientResponseFilter doesn't get called for exceptions (and thus the various and slightly odd JAXRS implementation-specific instrumentations).

And it makes it hard to propagate context because it's not clear to me that these two filters will be called in the same thread (e.g. JAXRS supports async http client calls returning Future).

But then I am really wondering what's the value of these JAXRS client spans over the underlying http client spans.

If the JAXRS client were captured at the top level where the application code interacted with it, I would see value. But as it is, the spans are captured in between where the application code interacts with it and the underlying http client, which seems to have very limited value.

Maybe we should capture these JAXRS spans where the application code interacts with it (e.g. javax.ws.rs.client.AsyncInvoker) and capture them as INTERNAL spans with their own convention. I think this could parallel the hibernate instrumentation, since they are both "object" interfaces on top of underlying http/sql.

But I'm not personally convinced that these INTERNAL spans would have a lot of value (similar to my opinion about the hibernate INTERNAL spans), so I'm proposing we just delete this instrumentation (but keep the tests, which still pass!) and wait for more user feedback to justify value in capturing INTERNAL spans.

EDIT on third thought, I'm sort of not sure what the point of keeping only the tests is, although they did uncover a bug in the HttpURLConnection instrumentation, and they are already written....

[trask]

@laurit curious your thoughts on this

[laurit]

@trask I agree with your analysis. The duplicate client span is definitely a bug. I wasn't able to find additional value over what http-url-connection or apache-httpclient instrumentation provides.