TCK doesn't use returned instrumented ClientBuilder

[pdudits]

TestClientRegistrarWebServices doesn't use the client returned from ClientTracingRegistrar as instrumented client.

The javadoc of ClientTracingRegistrar says "returns a ClientBuilder with enabled tracing integration.", therefore the test should not expect original builder to be fully instrumented.

[kenfinnigan]

Why not clarify the javadoc then, as the implementation clearly operates on the builder passed into the method?

[pavolloffay]

+1 we should fix the javadoc. The intention was to configure the builder and also return the same instance to allow chaining builder calls.

[pdudits]

The reason I opt for actually using the result is, that not all context propagation can be done my means of JAX-RS api, and I had to resort to decoration of the builder and client to capture context of rx() calls, which might not use the provided execution factory.

[kenfinnigan]

Any propagation that's required beyond that of the JAX-RS APIs, should be handled by MP Context Propagation.

My preference would still be for updating the javadoc only

[pavolloffay]

The reason I opt for actually using the result is, that not all context propagation can be done my means of JAX-RS api, and I had to resort to decoration of the builder and client to capture context of rx()

Could you please paste here a code sample? And also what implementation are you using? The ClientTracingRegistrar is there to install filters and instrument the executor service to propagate the context.

[pdudits]

I am implementing Jersey-based tracing for Payara. We used decoration for capturing calling (main) thread context for async calls at builder level, but recently decided to minimize its impact. Therefore we moved the decoration into ClientTracingRegistrar.

ExecutorService wrapping works for async calls, but IMO there's no guarantee of executor service being used when using Invocation.Builder#rx(), or that submission would happen on main thread. That's why being able to decorate in this method looks desirable to me.

But in parallel we'll be working towards direct support for context propagation within Jersey, that would work without any wrapping.