...

There are a couple of ways the JAX-RS client could be configured, depending on the client implementation. Apache CXF provides its own WebClient which could be configured just like that (in future versions, there would be a simpler ways to do that using client specific features):

// Configure the spans transport sender
final Sender sender = ...; 

/**
 * For example:
 *
 * final Sender sender = LibthriftSender.create("localhost");; 
 */
        
final Tracing brave = Tracing
    .newBuilder()
    .localServiceName("web-client")
    .reporter(AsyncReporter.builder(sender).build())
    .traceSampler(Sampler.ALWAYS_SAMPLE) /* or any other Sampler */
    .build();
        
Response response = WebClient
    .create("http://localhost:9000/catalog", Arrays.asList(new BraveClientProvider(brave)))
    .accept(MediaType.APPLICATION_JSON)
    .get();

The configuration based on using the standard JAX-RS Client is very similar:

// Configure the spans transport sender
final Sender sender = ...; 

/**
 * For example:
 *
 * final Sender sender = LibthriftSender.create("localhost");; 
 */
        
final Tracing brave = Tracing
    .newBuilder()
    .localServiceName("jaxrs-client")
    .reporter(AsyncReporter.builder(sender).build())
    .traceSampler(Sampler.ALWAYS_SAMPLE) /* or any other Sampler */
    .build();
                
final BraveClientProvider provider = new BraveClientProvider(brave);
final Client client = ClientBuilder.newClient().register(provider);

final Response response = client
    .target("http://localhost:9000/catalog")
    .request()
    .accept(MediaType.APPLICATION_JSON)
    .get();

...

The actual invocation of the request by the client (with service name tracer-client) and consequent invocation of the service on the server side (service name traceser-server) is going to generate the following sample traces:

Image RemovedImage Added

Example #4: Client and Server with binary annotations (key/value)

...

The actual invocation of the request by the client (with service name tracer-client) and consequent invocation of the service on the server side (process name tracer-server) is going to generate the following sample traces:

Image RemovedImage Added

Example #6: Client and Server with asynchronous JAX-RS service (server-side)

...

The actual invocation of the request by the client (with service name tracer-client) and consequent invocation of the service on the server side (service name tracer-server) is going to generate the following sample traces:

Image RemovedImage Added

Example #7: Client and Server with asynchronous invocation (client-side)

...

In this respect, there is no difference from the caller prospective however a bit more work is going under the hood to transfer the active tracing span from JAX-RS client request filter to client response filter as in general those are executed in different threads (similarly to server-side asynchronous JAX-RS resource invocation). The actual invocation of the request by the client (with service name tracer-client) and consequent invocation of the service on the server side (service name tracer-server) is going to generate the following sample traces:

Image RemovedImage Added

Distributed Tracing with OpenZipkin Brave and JAX-WS support

...

<bean id="braveFeature" class="org.apache.cxf.tracing.brave.BraveFeature"><!-- JAX-WS server feature -->
   <constructor-arg ref="httpTracing" />
</bean>

<bean id="httpTracing" class="brave.spring.beans.HttpTracingFactoryBean">
   <property name="tracing">
      <bean class="brave.spring.beans.TracingFactoryBean">
         <property name="localServiceName" value="myService"/>
         <property name="reporter">
            <bean class="brave.spring.beans.AsyncReporterFactoryBean">
               <property name="sender">
                  <bean class="zipkin.reporter.urlconnection.URLConnectionSender" factory-method="create">
                     <constructor-arg value="http://localhost:9411/api/v1/spans"/>
                  </bean>
               </property>
            </bean>
         </property>
         <property name="currentTraceContext">
            <bean class="brave.context.slf4j.MDCCurrentTraceContext" factory-method="create"/>
         </property>
      </bean>
   </property>
   <property name="clientParser">
      <bean class="org.apache.cxf.tracing.brave.HttpClientSpanParser" />
   </property>
   <property name="serverParser">
      <bean class="org.apache.cxf.tracing.brave.HttpServerSpanParser" />
   </property>
</bean>

Using non-JAX-RS clients

The  Apache CXF  uses native OpenZipkin Brave capabilities so the existing instrumentations for different HTTP clients work as expected. The usage of only JAX-RS client is not required. For example, the following snippet demonstrates the usage of traceble OkHttp client  to call JAX-RS resources, backed by Apache CXF .

final Tracing brave = Tracing
    .newBuilder()
    .localServiceName("web-client")
    .reporter(AsyncReporter.builder(sender).build())
    .traceSampler(Sampler.ALWAYS_SAMPLE) /* or any other Sampler */
    .build();

final OkHttpClient client = new OkHttpClient();
final Call.Factory factory = TracingCallFactory.create(brave, client);
            
final Request request = new Request.Builder()
    .url("http://localhost:9000/catalog")
    .header("Accept", "application/json")
    .build();

try (final Response response = factory.newCall(request).execute()) {
    // Do something with response.body()
}

Accessing Brave APIs

The Apache CXF  abstracts as much of the tracer-specific APIs behind TracerContext as possible. However, sometimes there is a need to get access to OpenZipkin Brave APIs in order to leverages the rich set of available instrumentations. To make it possible, TracerContext has a dedicated unwrap method which returns underlying HttpTracing, Tracer or Tracing instances. The snippet below shows off how to use this API and use OpenZipkin Brave instrumentation for Apache HttpClient.

@GET
@Path("/search")
@Produces(MediaType.APPLICATION_JSON)
public JsonObject search(@QueryParam("q") final String query, @Context final TracerContext tracing) throws Exception {
    final CloseableHttpClient httpclient = TracingHttpClientBuilder
        .create(tracing.unwrap(HttpTracing.class))
        .build();
    
    try {
        final URI uri = new URIBuilder("https://www.googleapis.com/books/v1/volumes")
            .setParameter("q", query)
            .build();
            
        final HttpGet request = new HttpGet(uri);
        request.setHeader("Accept", "application/json");
            
        final HttpResponse response = httpclient.execute(request);
        final String data = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8);
        try (final StringReader reader = new StringReader(data)) {
            return Json.createReader(reader).readObject();
        }
    } finally {
        httpclient.close();
    }
}

The usage of tracer-specific APIs is not generally advisable (because of portability reasons) but in case there are no other options available, it is available.