Author: buildbot
Date: Sun Aug 12 18:58:02 2018
New Revision: 1033859
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/using-opentracing.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/using-opentracing.html
==============================================================================
--- websites/production/cxf/content/docs/using-opentracing.html (original)
+++ websites/production/cxf/content/docs/using-opentracing.html Sun Aug 12
18:58:02 2018
@@ -34,6 +34,7 @@
<script src='/resources/highlighter/scripts/shCore.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -117,17 +118,21 @@ Apache CXF -- Using OpenTracing
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1
id="UsingOpenTracing-/*<![CDATA[*/div.rbtoc1524513408549{padding:0px;}div.rbtoc1524513408549ul{list-style:disc;margin-left:0px;}div.rbtoc1524513408549li{margin-left:0px;padding-left:0px;}/*]]>*/#UsingOpenTracing-Overview#UsingOpenTracing-OverviewDistributedTr"><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1524513408549 {padding: 0px;}
-div.rbtoc1524513408549 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1524513408549 li {margin-left: 0px;padding-left: 0px;}
-
-/*]]>*/</style></h1><div class="toc-macro rbtoc1524513408549">
-<ul class="toc-indentation"><li><a shape="rect"
href="#UsingOpenTracing-"></a></li><li><a shape="rect"
href="#UsingOpenTracing-Overview">Overview</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</a></li><li><a shape="rect"
href="#UsingOpenTracing-ConfiguringClient">Configuring Client</a></li><li><a
shape="rect" href="#UsingOpenTracing-ConfiguringServer">Configuring
Server</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</a>
+<div id="ConfluenceContent"><h1
id="UsingOpenTracing-/*<![CDATA[*/div.rbtoc1534100241912{padding:0px;}div.rbtoc1534100241912ul{list-style:disc;margin-left:0px;}div.rbtoc1534100241912li{margin-left:0px;padding-left:0px;}/*]]>*/#UsingOpenTracing-Overview#UsingOpenTracing-OverviewDistributedTr"><style
type="text/css">/*<![CDATA[*/
+div.rbtoc1534100241912 {padding: 0px;}
+div.rbtoc1534100241912 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1534100241912 li {margin-left: 0px;padding-left: 0px;}
+
+/*]]>*/</style></h1><div class="toc-macro rbtoc1534100241912">
+<ul class="toc-indentation"><li><a shape="rect"
href="#UsingOpenTracing-"></a></li><li><a shape="rect"
href="#UsingOpenTracing-Overview">Overview</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</a></li><li><a shape="rect"
href="#UsingOpenTracing-ANoteonOpenTracingAPIs">A Note on OpenTracing
APIs</a></li><li><a shape="rect"
href="#UsingOpenTracing-OpenTracingAPIv0.30.0andApacheCXF3.2.x">OpenTracing API
v0.30.0 and Apache CXF 3.2.x</a>
+<ul class="toc-indentation"><li><a shape="rect"
href="#UsingOpenTracing-ConfiguringClient">Configuring Client</a></li><li><a
shape="rect" href="#UsingOpenTracing-ConfiguringServer">Configuring
Server</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#UsingOpenTracing-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing
configured</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#2:ClientandServerwithnestedtrace">Example #2:
Client and Server with nested trace</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#3:ClientandServertracewithtimeline">Example #3:
Client and Server trace with timeline</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</a></li><li><a
shape="rect"
href="#UsingOpenTracing-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread
pools)</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Exampl
e #6: Client and Server with asynchronous JAX-RS service
(server-side)</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
</li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed
Tracing with OpenTracing and JAX-WS support</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracingwithOpenTracingandOSGi">Distributed
Tracing with OpenTracing and OSGi</a></li></ul>
-</div><h1 id="UsingOpenTracing-Overview">Overview</h1><p><a shape="rect"
class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> is a vendor-neutral open standard for
distributed tracing. Essentially, for Java-based projects the specification
exists as a set of <a shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
APIs</a> which any distributed tracing solution is welcome to implement. There
are<a shape="rect" class="external-link"
href="http://opentracing.io/documentation/pages/supported-tracers";
rel="nofollow"> quite a few distributed tracing frameworks</a> available which
are compatible with <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a>, notably <a
shape="rect" class="external-link" href="http://zipkin.io/";
rel="nofollow">Zipkin</a> (via community contributions like <a shape="rect"
class="external-link" href="https://github.com/openzipkin/brav
e-opentracing" rel="nofollow">bridge from Brave to OpenTracing</a> ), <a
shape="rect" class="external-link" href="http://lightstep.com/";
rel="nofollow">Lightstep</a> and <a shape="rect" class="external-link"
href="https://uber.github.io/jaeger/"; rel="nofollow">Jaeger</a>. Starting from
<strong>3.2.1</strong> release, Apache CXF fully supports integration (through
<strong>cxf-integration-tracing-opentracing</strong> module) with any
distributed tracer that provides <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> <a
shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> implementation.</p><p>The section <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+Apache+HTrace";>dedicated
to Apache HTrace </a>has pretty good introduction into distributed tracing
basics however <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="
nofollow">OpenTracing</a> specification abstracts a lot of things, outlining
just a general APIs to denote the <strong>Span </strong>lifecycle and
injection points to propagate the context across many distributed components.
As such, the intrinsic details about HTTP headers f.e. becomes an integral part
of the distributed tracer of your choice, out of reach for Apache CXF.</p><h1
id="UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</h1><p><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> is a very popular framework for
building services and web APIs. No doubts, it is going to play even more
important role in context of microservices architecture letting developers to
quickly build and deploy individual JAX-RS/JAX-WS services. Distributed tracing
is an essential technique to observe the application platform as a whole,
breaking the request to individual service traces as it goes through and
crosses the
boundaries of threads, processes and machines.</p><p>The current integration
of distributed tracing in <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> supports <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> <a
shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> <strong class="external-link">0.30.0+</strong> and provides
full-fledged support of JAX-RS 2.x / JAX-WS applications. From high-level
prospective, the JAX-RS integration consists of three main
parts:</p><ul><li><strong>TracerContext</strong> (injectable through
<strong>@Context</strong>
annotation)</li><li><strong>OpenTracingProvider</strong> (server-side JAX-RS
provider) and <strong>OpenTracingClientProvider</strong> (client-side JAX-RS
provider)</li><li class="external-link"><strong>OpenTracingFeature</strong>
(server-side JAX-RS feature) to simplify the configuration and integration<
/li></ul><p>Similarly, from high-level perspective, JAX-WS integration
includes:</p><ul><li><strong>OpenTracingStartInterceptor</strong> /
<strong>OpenTracingStopInterceptor</strong> /
<strong>OpenTracingFeature </strong><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> feature (server-side JAX-WS
support)</li><li><strong>OpenTracingClientStartInterceptor</strong> /
<strong>OpenTracingClientStopInterceptor</strong> /
<strong>OpenTracingClientFeature </strong><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> feature (client-side JAX-WS
support)</li></ul><p><a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> uses HTTP headers to hand off tracing context from the client to the
service and from the service to service. Those headers are specific to
distributing tracing framework you have picked and are not configurable at the
moment (unless the framework itself has a way to do that).</p><p>By default,
<strong>OpenTracingClientProvider</strong
> will try to pass the currently active <strong>span</strong> through HTTP
> headers on each service invocation. If there is no active spans, the new
> span will be created and passed through HTTP headers on per-invocation
> basis. Essentially, for JAX-RS applications just registering
> <strong>OpenTracingClientProvider</strong> on the client and
> <strong>OpenTracingProvider</strong> on the server is enough to have tracing
> context to be properly passed everywhere. The only configuration part which
> is necessary are <strong>span reports(s)</strong> and
> <strong>sampler</strong>(s) which are, not surprisingly, specific to
> distributing tracing framework you have chosen.</p><p>It is also worth to
> mention the way <a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a>
> attaches the description to <strong>spans</strong>. With regards to the
> client integration, the description becomes a full URL being invoked
> prefixed by HTTP method, for example: <strong>GET </strong><a shape="rect"
> class="extern
al-link" href="http://localhost:8282/books";
rel="nofollow"><strong>http://localhost:8282</strong>/books</a>. On the server
side integration, the description becomes a relative JAX-RS resource path
prefixed by HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1
id="UsingOpenTracing-ConfiguringClient">Configuring Client</h1><p>In this
section and below, all the code snippets are going to be based on <a
shape="rect" class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a> distributed tracing framework (<strong>release
0.20.6+</strong>), although everything we are going to discuss is equally
applicable to any other existing alternatives. Essentially, the only dependency
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> integration relies
on is the <strong>Tracer</strong> instance.</p><p>There are a couple of ways
the JAX-RS client could be configured, depending on the client implementation.
<a shape="rect" href="http://cxf.apache.o
rg/">Apache CXF</a> provides its own <strong>WebClient</strong> which could be
configured just like that (in future versions, there would be a simpler ways to
do that using client specific features):</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new Configuration("web-client",
+</li><li><a shape="rect"
href="#UsingOpenTracing-OpenTracingAPIv0.31.0andApacheCXF3.3.x">OpenTracing API
v0.31.0 and Apache CXF 3.3.x</a>
+<ul class="toc-indentation"><li><a shape="rect"
href="#UsingOpenTracing-ConfiguringClient.1">Configuring Client</a></li><li><a
shape="rect" href="#UsingOpenTracing-ConfiguringServer.1">Configuring
Server</a></li></ul>
+</li></ul>
+</div><h1 id="UsingOpenTracing-Overview">Overview</h1><p><a shape="rect"
class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> is a vendor-neutral open standard for
distributed tracing. Essentially, for Java-based projects the specification
exists as a set of <a shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
APIs</a> which any distributed tracing solution is welcome to implement. There
are<a shape="rect" class="external-link"
href="http://opentracing.io/documentation/pages/supported-tracers";
rel="nofollow"> quite a few distributed tracing frameworks</a> available which
are compatible with <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a>, notably <a
shape="rect" class="external-link" href="http://zipkin.io/";
rel="nofollow">Zipkin</a> (via community contributions like <a shape="rect"
class="external-link" href="https://github.com/openzipkin/brav
e-opentracing" rel="nofollow">bridge from Brave to OpenTracing</a> ), <a
shape="rect" class="external-link" href="http://lightstep.com/";
rel="nofollow">Lightstep</a> and <a shape="rect" class="external-link"
href="https://uber.github.io/jaeger/"; rel="nofollow">Jaeger</a>. Starting from
<strong>3.2.1</strong> release, Apache CXF fully supports integration (through
<strong>cxf-integration-tracing-opentracing</strong> module) with any
distributed tracer that provides <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> <a
shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> implementation.</p><p>The section <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+Apache+HTrace";>dedicated
to Apache HTrace </a>has pretty good introduction into distributed tracing
basics however <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="
nofollow">OpenTracing</a> specification abstracts a lot of things, outlining
just a general APIs to denote the <strong>Span </strong>lifecycle and
injection points to propagate the context across many distributed components.
As such, the intrinsic details about HTTP headers f.e. becomes an integral part
of the distributed tracer of your choice, out of reach for Apache CXF.</p><h1
id="UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</h1><p><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> is a very popular framework for
building services and web APIs. No doubts, it is going to play even more
important role in context of microservices architecture letting developers to
quickly build and deploy individual JAX-RS/JAX-WS services. Distributed tracing
is an essential technique to observe the application platform as a whole,
breaking the request to individual service traces as it goes through and
crosses the
boundaries of threads, processes and machines.</p><p>The current integration
of distributed tracing in <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> supports <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> <a
shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> <strong class="external-link">0.30.0+</strong> and provides
full-fledged support of JAX-RS 2.x / JAX-WS applications. From high-level
prospective, the JAX-RS integration consists of three main
parts:</p><ul><li><strong>TracerContext</strong> (injectable through
<strong>@Context</strong>
annotation)</li><li><strong>OpenTracingProvider</strong> (server-side JAX-RS
provider) and <strong>OpenTracingClientProvider</strong> (client-side JAX-RS
provider)</li><li class="external-link"><strong>OpenTracingFeature</strong>
(server-side JAX-RS feature) to simplify the configuration and integration<
/li></ul><p>Similarly, from high-level perspective, JAX-WS integration
includes:</p><ul><li><strong>OpenTracingStartInterceptor</strong> /
<strong>OpenTracingStopInterceptor</strong> /
<strong>OpenTracingFeature </strong><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> feature (server-side JAX-WS
support)</li><li><strong>OpenTracingClientStartInterceptor</strong> /
<strong>OpenTracingClientStopInterceptor</strong> /
<strong>OpenTracingClientFeature </strong><a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> feature (client-side JAX-WS
support)</li></ul><p><a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> uses HTTP headers to hand off tracing context from the client to the
service and from the service to service. Those headers are specific to
distributing tracing framework you have picked and are not configurable at the
moment (unless the framework itself has a way to do that).</p><p>By default,
<strong>OpenTracingClientProvider</strong
> will try to pass the currently active <strong>span</strong> through HTTP
> headers on each service invocation. If there is no active spans, the new
> span will be created and passed through HTTP headers on per-invocation
> basis. Essentially, for JAX-RS applications just registering
> <strong>OpenTracingClientProvider</strong> on the client and
> <strong>OpenTracingProvider</strong> on the server is enough to have tracing
> context to be properly passed everywhere. The only configuration part which
> is necessary are <strong>span reporters(s)</strong> and
> <strong>sampler(s)</strong> which are, not surprisingly, specific to
> distributing tracing framework you have chosen.</p><p>It is also worth to
> mention the way <a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a>
> attaches the description to <strong>spans</strong>. With regards to the
> client integration, the description becomes a full URL being invoked
> prefixed by HTTP method, for example: <strong>GET </strong><a shape="rect"
> class="exte
rnal-link" href="http://localhost:8282/books";
rel="nofollow"><strong>http://localhost:8282</strong>/books</a>. On the server
side integration, the description becomes a relative JAX-RS resource path
prefixed by HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1
id="UsingOpenTracing-ANoteonOpenTracingAPIs">A Note on OpenTracing
APIs</h1><p><a shape="rect" class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> <a shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> is evolving very fast and, sadly but not surprisingly, often the
changes being made are not backward compatible. The <a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> <strong>3.2.x</strong> release
branch stays on <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> <a
shape="rect" class="external-link"
href="https://github.com/opentracing/opentracin
g-java" rel="nofollow">Java API</a> <strong
class="external-link">0.30.0 </strong>as of now, while the <a shape="rect"
href="http://cxf.apache.org/";>Apache CXF</a> <strong>3.3.x</strong> is using <a
shape="rect" class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> <a shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java"; rel="nofollow">Java
API</a> <strong class="external-link">0.31.0</strong>. There are<strong
class="external-link"> </strong>quite many major differences between both APIs
but <a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> is trying hard
to smooth it over. It is worth to mention that <a shape="rect"
class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a>-compatible clients and servers may not depend on
the same APIs version, the only issue you will run into is related to
compatibility of the provided Java clients for the tracer of your choice.</p><
h1 id="UsingOpenTracing-OpenTracingAPIv0.30.0andApacheCXF3.2.x">OpenTracing
API v0.30.0 and Apache CXF 3.2.x</h1><h2
id="UsingOpenTracing-ConfiguringClient">Configuring Client</h2><p>In this
section and below, all the code snippets are going to be based on <a
shape="rect" class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a> distributed tracing framework (<strong>release
0.20.6+</strong>), although everything we are going to discuss is equally
applicable to any other existing alternatives. Essentially, the only dependency
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> integration relies
on is the <strong>Tracer</strong> instance.</p><p>There are a couple of ways
the JAX-RS client could be configured, depending on the client implementation.
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> provides its own
<strong>WebClient</strong> which could be configured just like that (in future
versions, there would be a simpler ways to d
o that using client specific features):</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("web-client",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -137,7 +142,7 @@ Response response = WebClient
.accept(MediaType.APPLICATION_JSON)
.get();</pre>
</div></div><p>The configuration based on using the standard JAX-RS
<strong>Client</strong> is very similar:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new Configuration("jaxrs-client",
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("jaxrs-client",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -151,7 +156,7 @@ final Response response = client
.accept(MediaType.APPLICATION_JSON)
.get();</pre>
</div></div><p>Alternatively, you may use <strong>GlobalTracer</strong> to
pass the tracer around, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new Configuration("jaxrs-client",
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("jaxrs-client",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -161,8 +166,8 @@ GlobalTracer.register(tracer);
// No explicit Tracer instance is required, it will be picked off the
GlobalTracer using get() method
final OpenTracingClientProvider provider = new
OpenTracingClientProvider();</pre>
-</div></div><h1 id="UsingOpenTracing-ConfiguringServer">Configuring
Server</h1><p>Server configuration is a bit simpler than the client one thanks
to the feature class available, <strong>OpenTracingFeature</strong>. Depending
on the way the <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> is used to configure JAX-RS services, it could be part of JAX-RS
application configuration, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@ApplicationPath( "/" )
+</div></div><h2 id="UsingOpenTracing-ConfiguringServer">Configuring
Server</h2><p>Server configuration is a bit simpler than the client one thanks
to the feature class available, <strong>OpenTracingFeature</strong>. Depending
on the way the <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> is used to configure JAX-RS services, it could be part of JAX-RS
application configuration, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@ApplicationPath( "/" )
public class CatalogApplication extends Application {
@Override
public Set<Object> getSingletons() {
@@ -180,7 +185,7 @@ public class CatalogApplication extends
}
}</pre>
</div></div><p>Or it could be configured using
<strong>JAXRSServerFactoryBean</strong> as well, for example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new
Configuration("tracer-server",
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("tracer-server",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -190,7 +195,7 @@ factory.setProvider(new OpenTracingFeatu
...
return factory.create();</pre>
</div></div><p>Alternatively, you may rely on <strong>GlobalTracer</strong> to
pass the tracer around, so in this case the <strong>OpenTracingFeature</strong>
will pick it up from there, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@ApplicationPath( "/" )
+<pre class="brush: java; gutter: false; theme: Default">@ApplicationPath( "/" )
public class CatalogApplication extends Application {
@Override
public Set<Object> getSingletons() {
@@ -202,8 +207,8 @@ public class CatalogApplication extends
);
}
}</pre>
-</div></div><p>Once the <strong>span reporter</strong> and
<strong>sampler</strong> are properly configured, all generated
<strong>spans</strong> are going to be collected and available for analysis
and/or visualization.</p><h1
id="UsingOpenTracing-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</h1><p class="confluence-link">In the
following subsections we are going to walk through many different scenarios to
illustrate the distributed tracing in action, starting from the simplest ones
and finishing with asynchronous JAX-RS services. All examples assume that
configuration <strong>has been done</strong> (see please <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+OpenTracing#UsingOpenTracing-ConfiguringClient";><span
class="confluence-link"><span class="confluence-link">Configuring
Client</span></span></a><span class="confluence-link"> </span> and<a
shape="rect" href="https://cwiki.apache.org/confluence/di
splay/CXF20DOC/Using+OpenTracing#UsingOpenTracing-configuringserver"><span
class="confluence-link"> </span></a><a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+OpenTracing#UsingOpenTracing-ConfiguringServer";><span
class="confluence-link">Configuring Server</span></a> sections above).</p><h2
id="UsingOpenTracing-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</h2><p>In
the first example we are going to see the effect of using default configuration
on the client and on the server, with only
<strong>OpenTracingClientProvider</strong>  and
<strong><strong>OpenTracing</strong>Provider</strong> registered. The JAX-RS
resource endpoint is pretty basic stubbed method:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>Once the <strong>span reporter</strong> and
<strong>sampler</strong> are properly configured, all generated
<strong>spans</strong> are going to be collected and available for analysis
and/or visualization.</p><h2
id="UsingOpenTracing-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</h2><p class="confluence-link">In the
following subsections we are going to walk through many different scenarios to
illustrate the distributed tracing in action, starting from the simplest ones
and finishing with asynchronous JAX-RS services. All examples assume that
configuration <strong>has been done</strong> (see please <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+OpenTracing#UsingOpenTracing-ConfiguringClient";><span
class="confluence-link"><span class="confluence-link">Configuring
Client</span></span></a><span class="confluence-link"> </span> and<a
shape="rect" href="https://cwiki.apache.org/confluence/di
splay/CXF20DOC/Using+OpenTracing#UsingOpenTracing-configuringserver"><span
class="confluence-link"> </span></a><a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+OpenTracing#UsingOpenTracing-ConfiguringServer";><span
class="confluence-link">Configuring Server</span></a> sections above).</p><h3
id="UsingOpenTracing-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</h3><p>In
the first example we are going to see the effect of using default configuration
on the client and on the server, with only
<strong>OpenTracingClientProvider</strong>  and
<strong><strong>OpenTracing</strong>Provider</strong> registered. The JAX-RS
resource endpoint is pretty basic stubbed method:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks() {
return Arrays.asList(
@@ -211,13 +216,13 @@ public Collection<Book> getBooks()
);
}</pre>
</div></div><p>The client is as simple as that:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Response response = client
+<pre class="brush: java; gutter: false; theme: Default">final Response
response = client
.target("http://localhost:8282/books";)
.request()
.accept(MediaType.APPLICATION_JSON)
.get();</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-client</strong>) and consequent invocation of the
service on the server side (service name<strong> tracer-server</strong>) is
going to generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2012:41:7.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2013:18
:20.png"></span></p><h2
id="UsingOpenTracing-Example#2:ClientandServerwithnestedtrace">Example #2:
Client and Server with nested trace</h2><p>In this example server-side
implementation of the JAX-RS service is going to call an external system
(simulated as a simple delay of 500ms) within its own span. The client-side
code stays unchanged.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-client</strong>) and consequent invocation of the
service on the server side (service name<strong> tracer-server</strong>) is
going to generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2012:41:7.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2013:18
:20.png"></span></p><h3
id="UsingOpenTracing-Example#2:ClientandServerwithnestedtrace">Example #2:
Client and Server with nested trace</h3><p>In this example server-side
implementation of the JAX-RS service is going to call an external system
(simulated as a simple delay of 500ms) within its own span. The client-side
code stays unchanged.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
try(final ActiveSpan scope = tracer.startSpan("Calling External System")) {
@@ -229,8 +234,8 @@ public Collection<Book> getBooks(@
);
}
}</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered"><strong>tracer</strong>-client</span></strong>) and
consequent invocation of the service on the server side (service
name<strong><span class="label label-default service-filter-label"><strong>
tracer-</strong>server</span></strong><span class="label label-default
service-filter-label">)</span> is going to generate the following sample traces
(taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:9:7.png"></span></p><p>The same
trace will be looking pretty similar using traditional <a shape="rect"
class="external-link" href="https://github.com/openzipkin/zipkin/tree/mast
er/zipkin-ui" rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:10:40.png"></span></p><h2
id="UsingOpenTracing-Example#3:ClientandServertracewithtimeline">Example #3:
Client and Server trace with timeline</h2><p>In this example server-side
implementation of the JAX-RS service is going to add timeline to the active
span. The client-side code stays unchanged.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered"><strong>tracer</strong>-client</span></strong>) and
consequent invocation of the service on the server side (service
name<strong><span class="label label-default service-filter-label"><strong>
tracer-</strong>server</span></strong><span class="label label-default
service-filter-label">)</span> is going to generate the following sample traces
(taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:9:7.png"></span></p><p>The same
trace will be looking pretty similar using traditional <a shape="rect"
class="external-link" href="https://github.com/openzipkin/zipkin/tree/mast
er/zipkin-ui" rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:10:40.png"></span></p><h3
id="UsingOpenTracing-Example#3:ClientandServertracewithtimeline">Example #3:
Client and Server trace with timeline</h3><p>In this example server-side
implementation of the JAX-RS service is going to add timeline to the active
span. The client-side code stays unchanged.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
tracer.timeline("Preparing Books");
@@ -241,8 +246,8 @@ public Collection<Book> getBooks(@
new Book("Apache CXF Web Service Development", "Naveen Balani, Rajeev
Hathi")
);
}</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered">tracer-client</span></strong>) and consequent invocation
of the service on the server side (service name<strong> <span class="label
label-default service-filter-label">traceser-server</span></strong>) is going
to generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="400"
src="using-opentracing.data/image2017-9-10%2014:26:23.png"></span></p><p> </p><div
class="confluence-information-macro
confluence-information-macro-information"><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Please
notice that timelines are treated as<strong> logs events</strong> in <a
shape="rect" class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a>.</p></div></div><p>The same trace will be looking
pretty similar using traditional <a shape="rect" class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:19:1.png"></span></p><h2
id="UsingOpenTracing-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</h2><p>In this
example server-side implementation of the JAX-RS service is going to add
key/value annotations to the active span. The client-side code stays
unchanged.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeC
ontent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered">tracer-client</span></strong>) and consequent invocation
of the service on the server side (service name<strong> <span class="label
label-default service-filter-label">traceser-server</span></strong>) is going
to generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="400"
src="using-opentracing.data/image2017-9-10%2014:26:23.png"></span></p><p> </p><div
class="confluence-information-macro
confluence-information-macro-information"><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Please
notice that timelines are treated as<strong> logs events</strong> in <a
shape="rect" class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a>.</p></div></div><p>The same trace will be looking
pretty similar using traditional <a shape="rect" class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:19:1.png"></span></p><h3
id="UsingOpenTracing-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</h3><p>In this
example server-side implementation of the JAX-RS service is going to add
key/value annotations to the active span. The client-side code stays
unchanged.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeC
ontent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
final Collection<Book> books = Arrays.asList(
@@ -252,8 +257,8 @@ public Collection<Book> getBooks(@
tracer.annotate("# of books", Integer.toString(books.size()));
return books;
}</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered"><strong><span class="label label-default
service-filter-label
service-tag-filtered"><strong>tracer</strong></span></strong>-client</span></strong>)
and consequent invocation of the service on the server side (service
name<strong> tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample server trace properties (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="400"
src="using-opentracing.data/image2017-9-10%2014:40:20.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link" href="https:
//github.com/openzipkin/zipkin/tree/master/zipkin-ui" rel="nofollow">Zipkin
UI</a> frontend:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:46:4.png"></span></p><h2
id="UsingOpenTracing-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread pools)</h2><p>In
this example server-side implementation of the JAX-RS service is going to
offload some work into thread pool and then return the response to the client,
simulating parallel execution. The client-side code stays unchanged.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong><span class="label label-default service-filter-label
service-tag-filtered"><strong><span class="label label-default
service-filter-label
service-tag-filtered"><strong>tracer</strong></span></strong>-client</span></strong>)
and consequent invocation of the service on the server side (service
name<strong> tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample server trace properties (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="400"
src="using-opentracing.data/image2017-9-10%2014:40:20.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link" href="https:
//github.com/openzipkin/zipkin/tree/master/zipkin-ui" rel="nofollow">Zipkin
UI</a> frontend:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:46:4.png"></span></p><h3
id="UsingOpenTracing-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread pools)</h3><p>In
this example server-side implementation of the JAX-RS service is going to
offload some work into thread pool and then return the response to the client,
simulating parallel execution. The client-side code stays unchanged.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
final Future<Book> book1 = executor.submit(
@@ -282,8 +287,8 @@ public Collection<Book> getBooks(@
return Arrays.asList(book1.get(), book2.get());
}</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-<span class="label label-default
service-filter-label service-tag-filtered">client</span></strong>) and
consequent invocation of the service on the server side (process name<strong>
tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:49:4.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-fil
e-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:50:2.png"></span></p><h2
id="UsingOpenTracing-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Example
#6: Client and Server with asynchronous JAX-RS service (server-side)</h2><p>In
this example server-side implementation of the JAX-RS service is going to be
executed asynchronously. It poses a challenge from the tracing prospective as
request and response are processed in different threads (in general). At the
moment, <a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> does not
support the transparent tracing spans management (except for default use case)
but provides the simple ways to do that (by letting to transfer spans from
thread to thread). The client-side code stays unchanged.</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-<span class="label label-default
service-filter-label service-tag-filtered">client</span></strong>) and
consequent invocation of the service on the server side (process name<strong>
tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:49:4.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-fil
e-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:50:2.png"></span></p><h3
id="UsingOpenTracing-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Example
#6: Client and Server with asynchronous JAX-RS service (server-side)</h3><p>In
this example server-side implementation of the JAX-RS service is going to be
executed asynchronously. It poses a challenge from the tracing prospective as
request and response are processed in different threads (in general). At the
moment, <a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> does not
support the transparent tracing spans management (except for default use case)
but provides the simple ways to do that (by letting to transfer spans from
thread to thread). The client-side code stays unchanged.</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public void getBooks(@Suspended final AsyncResponse response, @Context final
TracerContext tracer) throws Exception {
tracer.continueSpan(new Traceable<Future<Void>>() {
@@ -307,8 +312,8 @@ public void getBooks(@Suspended final As
}
});
}</pre>
-</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-<span class="label label-default
service-filter-label service-tag-filtered">client</span></strong>) and
consequent invocation of the service on the server side (service name<strong>
tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:54:2.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-fil
e-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:55:0.png"></span></p><h2
id="UsingOpenTracing-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</h2><p>In
this example server-side implementation of the JAX-RS service is going to be
the default one:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-<span class="label label-default
service-filter-label service-tag-filtered">client</span></strong>) and
consequent invocation of the service on the server side (service name<strong>
tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui"; rel="nofollow">Jaeger
UI</a>):</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2014:54:2.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-fil
e-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:55:0.png"></span></p><h3
id="UsingOpenTracing-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</h3><p>In
this example server-side implementation of the JAX-RS service is going to be
the default one:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@Produces( {
MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks() {
return Arrays.asList(
@@ -316,14 +321,14 @@ public Collection<Book> getBooks()
);
}</pre>
</div></div><p>While the JAX-RS client implementation is going to perform
the asynchronous invocation:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Future<Response> future = client
+<pre class="brush: java; gutter: false; theme: Default">final
Future<Response> future = client
.target("http://localhost:8282/books";)
.request()
.accept(MediaType.APPLICATION_JSON)
.async()
.get();</pre>
-</div></div><p>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 <strong>tracer-<span class="label
label-default service-filter-label
service-tag-filtered">client</span></strong>) and consequent invocation of the
service on the server side (service name<strong> tracer-<span class="label
label-default service-filter-label">server</span></strong>) is going to
generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2015:0:49.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:58:53.png"></span></p><h1
id="UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed
Tracing with OpenTracing and JAX-WS support</h1><p>Distributed tracing in the
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> is build primarily
around JAX-RS 2.x implementation. However, JAX-WS is also supported but it
requires to write some boiler-plate code and use <a shape="rect"
class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> <a shape="rect" cla
ss="external-link" href="https://github.com/opentracing/opentracing-java";
rel="nofollow">Java API</a> directly (the JAX-WS integration is going to be
enhanced in the future). Essentially, from the server-side prospective the
in/out interceptors, <strong>OpenTracingStartInterceptor</strong> and
<strong><strong>OpenTracing</strong>StopInterceptor </strong>respectively,
should be configured as part of interceptor chains, either manually or using
<strong><strong>OpenTracing</strong>Feature</strong>. For example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new Configuration("tracer",
+</div></div><p>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 <strong>tracer-<span class="label
label-default service-filter-label
service-tag-filtered">client</span></strong>) and consequent invocation of the
service on the server side (service name<strong> tracer-<span class="label
label-default service-filter-label">server</span></strong>) is going to
generate the following sample traces (taken from <a shape="rect"
class="external-link" href="https://github.com/uber/jaeger-ui";
rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image"
height="250"
src="using-opentracing.data/image2017-9-10%2015:0:49.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect"
class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui";
rel="nofollow">Zipkin UI</a> frontend:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:58:53.png"></span></p><h2
id="UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed
Tracing with OpenTracing and JAX-WS support</h2><p>Distributed tracing in the
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> is build primarily
around JAX-RS 2.x implementation. However, JAX-WS is also supported but it
requires to write some boiler-plate code and use <a shape="rect"
class="external-link" href="http://opentracing.io/";
rel="nofollow">OpenTracing</a> <a shape="rect" cla
ss="external-link" href="https://github.com/opentracing/opentracing-java";
rel="nofollow">Java API</a> directly (the JAX-WS integration is going to be
enhanced in the future). Essentially, from the server-side prospective the
in/out interceptors, <strong>OpenTracingStartInterceptor</strong> and
<strong><strong>OpenTracing</strong>StopInterceptor </strong>respectively,
should be configured as part of interceptor chains, either manually or using
<strong><strong>OpenTracing</strong>Feature</strong>. For example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("tracer",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -334,7 +339,7 @@ sf.getFeatures().add(new OpenTracingFeat
...
sf.create();</pre>
</div></div><p>Similarly to the server-side, client-side needs own set of
out/in interceptors,
<strong><strong>OpenTracing</strong>ClientStartInterceptor</strong> and
<strong><strong>OpenTracing</strong>ClientStopInterceptor</strong> (or
<strong><strong>OpenTracing</strong>ClientFeature</strong>). Please notice the
difference from server-side: 
<strong><strong>OpenTracing</strong>ClientStartInterceptor</strong> becomes
out-interceptor while
<strong><strong>OpenTracing</strong>ClientStopInterceptor</strong> becomes
in-interceptor. For example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Tracer tracer = new Configuration("tracer",
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("tracer",
new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
).getTracer();
@@ -346,8 +351,8 @@ sf.getFeatures().add(new OpenTracingClie
sf.create();
</pre>
-</div></div><p>As it was mentioned before, you may use
<strong>GlobalTracer</strong> utility class to pass the tracer around so, for
example, any JAX-WS service will be able to retrieve the current tracer by
invoking <strong>GlobalTracer.get()</strong> method.</p><h1
id="UsingOpenTracing-DistributedTracingwithOpenTracingandOSGi">Distributed
Tracing with OpenTracing and OSGi</h1><p class="external-link">Most of the
distributed tracers compatible with <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> API could be
deployed into <strong>OSGi</strong> container and as such, the integration is
fully available for <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> services running inside the container. For a complete example please
take a look on <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/master/distribution/src/main/release/samples/jax_rs_tracing_opentracing_osgi/README.txt";
rel="nofollow">jax_rs_tra
cing_opentracing_osgi</a> sample project, but here is the typical
<strong>OSGi</strong>  Blueprint snippet in case of <a shape="rect"
class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a>.</p><p class="external-link"> </p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+</div></div><p>As it was mentioned before, you may use
<strong>GlobalTracer</strong> utility class to pass the tracer around so, for
example, any JAX-WS service will be able to retrieve the current tracer by
invoking <strong>GlobalTracer.get()</strong> method.</p><h2
id="UsingOpenTracing-DistributedTracingwithOpenTracingandOSGi">Distributed
Tracing with OpenTracing and OSGi</h2><p class="external-link">Most of the
distributed tracers compatible with <a shape="rect" class="external-link"
href="http://opentracing.io/"; rel="nofollow">OpenTracing</a> API could be
deployed into <strong>OSGi</strong> container and as such, the integration is
fully available for <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> services running inside the container. For a complete example please
take a look on <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/master/distribution/src/main/release/samples/jax_rs_tracing_opentracing_osgi/README.txt";
rel="nofollow">jax_rs_tra
cing_opentracing_osgi</a> sample project, but here is the typical
<strong>OSGi</strong>  Blueprint snippet in case of <a shape="rect"
class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a>.</p><p class="external-link"> </p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: xml; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:cxf="http://cxf.apache.org/blueprint/core";
@@ -409,7 +414,131 @@ sf.create();
</jaxrs:providers>
</jaxrs:server>
</blueprint></pre>
-</div></div><p> </p><p> </p></div>
+</div></div><h1
id="UsingOpenTracing-OpenTracingAPIv0.31.0andApacheCXF3.3.x">OpenTracing API
v0.31.0 and Apache CXF 3.3.x</h1><h2
id="UsingOpenTracing-ConfiguringClient.1">Configuring Client</h2><p>In this
section and below, all the code snippets are going to be based on <a
shape="rect" class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a> distributed tracing framework (<strong>release
0.30.3+</strong>), although everything we are going to discuss is equally
applicable to any other existing alternatives. Essentially, the only dependency
<a shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> integration relies
on is the <strong>Tracer</strong> instance. <a shape="rect"
class="external-link" href="https://uber.github.io/jaeger/";
rel="nofollow">Jaeger</a> uses service Java's <a shape="rect"
class="external-link"
href="https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html";
rel="nofollow">ServiceLoader</a> mechanism to determine the
instance of the tracer to use, so it is necessary to provide
<strong>META-INF/services/io.jaegertracing.spi.SenderFactory</strong> binding,
for example:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme:
Default">io.jaegertracing.thrift.internal.senders.ThriftSenderFactory</pre>
+</div></div><p>Alternatively, you may just provide own implementation of the
<strong>SenderConfiguration</strong> with the override
<strong>getSender</strong> method, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final
SenderConfiguration senderConfiguration = new SenderConfiguration() {
+ @Override
+ public Sender getSender() {
+ return ...; /* the Sender implementation */
+ }
+}</pre>
+</div></div><p><br clear="none"></p><p>There are a couple of ways the JAX-RS
client could be configured, depending on the client implementation. <a
shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> provides its own
<strong>WebClient</strong> which could be configured just like that (in future
versions, there would be a simpler ways to do that using client specific
features):</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("web-client")
+ .withSampler(
+ new SamplerConfiguration()
+ .withType(ConstSampler.TYPE)
+ .withParam(1)
+ )
+ .withReporter(
+ new ReporterConfiguration()
+ .withSender(
+ new SenderConfiguration()
+ .withEndpoint("http://localhost:14268/api/traces";)
+ )
+ )
+ .getTracer();
+
+Response response = WebClient
+ .create("http://localhost:9000/catalog";, Arrays.asList(new
OpenTracingClientProvider(tracer)))
+ .accept(MediaType.APPLICATION_JSON)
+ .get();</pre>
+</div></div><p>The configuration based on using the standard JAX-RS
<strong>Client</strong> is very similar:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("jaxrs-client",
+ new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or
any other Sampler */
+ new Configuration.ReporterConfiguration(new
HttpSender("http://localhost:14268/api/traces";)) /* or any other Sender */
+ ).getTracer();
+
+final OpenTracingClientProvider provider = new
OpenTracingClientProvider(tracer);
+final Client client = ClientBuilder.newClient().register(provider);
+
+final Response response = client
+ .target("http://localhost:9000/catalog";)
+ .request()
+ .accept(MediaType.APPLICATION_JSON)
+ .get();</pre>
+</div></div><p>Alternatively, you may use <strong>GlobalTracer</strong> to
pass the tracer around, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("jaxrs-client")
+ .withSampler(
+ new SamplerConfiguration()
+ .withType(ConstSampler.TYPE)
+ .withParam(1)
+ )
+ .withReporter(
+ new ReporterConfiguration()
+ .withSender(
+ new SenderConfiguration()
+ .withEndpoint("http://localhost:14268/api/traces";)
+ )
+ )
+ .getTracer();
+
+// This method should only be called once during the application
initialization phase.
+GlobalTracer.register(tracer);
+
+// No explicit Tracer instance is required, it will be picked off the
GlobalTracer using get() method
+final OpenTracingClientProvider provider = new
OpenTracingClientProvider();</pre>
+</div></div><h2 id="UsingOpenTracing-ConfiguringServer.1">Configuring
Server</h2><p>Server configuration is a bit simpler than the client one thanks
to the feature class available, <strong>OpenTracingFeature</strong>. Depending
on the way the <a shape="rect" href="http://cxf.apache.org/";>Apache
CXF</a> is used to configure JAX-RS services, it could be part of JAX-RS
application configuration, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@ApplicationPath( "/" )
+public class CatalogApplication extends Application {
+ @Override
+ public Set<Object> getSingletons() {
+ final Tracer tracer = new Configuration("tracer-server")
+ .withSampler(
+ new SamplerConfiguration()
+ .withType(ConstSampler.TYPE)
+ .withParam(1)
+ )
+ .withReporter(
+ new ReporterConfiguration()
+ .withSender(
+ new SenderConfiguration()
+ .withEndpoint("http://localhost:14268/api/traces";)
+ )
+ )
+ .getTracer();
+
+ return new HashSet<>(
+ Arrays.asList(
+ new OpenTracingFeature(tracer)
+ )
+ );
+ }
+}</pre>
+</div></div><p>Or it could be configured using
<strong>JAXRSServerFactoryBean</strong> as well, for example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracer tracer =
new Configuration("tracer-server")
+ .withSampler(
+ new SamplerConfiguration()
+ .withType(ConstSampler.TYPE)
+ .withParam(1)
+ )
+ .withReporter(
+ new ReporterConfiguration()
+ .withSender(
+ new SenderConfiguration()
+ .withEndpoint("http://localhost:14268/api/traces";)
+ )
+ )
+ .getTracer();
+
+final JAXRSServerFactoryBean factory =
RuntimeDelegate.getInstance().createEndpoint(/* application instance */,
JAXRSServerFactoryBean.class);
+factory.setProvider(new OpenTracingFeature(tracer));
+...
+return factory.create();</pre>
+</div></div><p>Alternatively, you may rely on <strong>GlobalTracer</strong> to
pass the tracer around, so in this case the <strong>OpenTracingFeature</strong>
will pick it up from there, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">@ApplicationPath( "/" )
+public class CatalogApplication extends Application {
+ @Override
+ public Set<Object> getSingletons() {
+ return new HashSet<>(
+ Arrays.asList(
+ // No explicit Tracer instance is required, it will be
picked off the GlobalTracer using get() method
+ new OpenTracingFeature()
+ )
+ );
+ }
+}</pre>
+</div></div><p>Once the <strong>span reporter</strong> and
<strong>sampler</strong> are properly configured, all generated
<strong>spans</strong> are going to be collected and available for analysis
and/or visualization.</p></div>
</div>
<!-- Content -->
</td>
