Author: buildbot
Date: Tue Jan 31 01:47:06 2017
New Revision: 1005950

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/using-apache-htrace.html
    websites/production/cxf/content/docs/using-openzipkin-brave.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/using-apache-htrace.html
==============================================================================
--- websites/production/cxf/content/docs/using-apache-htrace.html (original)
+++ websites/production/cxf/content/docs/using-apache-htrace.html Tue Jan 31 
01:47:06 2017
@@ -117,19 +117,19 @@ Apache CXF -- Using Apache HTrace
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1485816393306 {padding: 0px;}
-div.rbtoc1485816393306 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1485816393306 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1485827192918 {padding: 0px;}
+div.rbtoc1485827192918 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1485827192918 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1485816393306">
+/*]]>*/</style></p><div class="toc-macro rbtoc1485827192918">
 <ul class="toc-indentation"><li><a shape="rect" 
href="#UsingApacheHTrace-Overview">Overview</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing in 
Nutshell</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
 Tracing in Apache CXF using Apache HTrace</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring 
Client</a>
 <ul class="toc-indentation"><li><a shape="rect" 
href="#UsingApacheHTrace-Configuringtracingheadernames">Configuring tracing 
header names</a></li></ul>
 </li><li><a shape="rect" 
href="#UsingApacheHTrace-ConfiguringServerconfigure.server">Configuring 
Server</a>
 <ul class="toc-indentation"><li><a shape="rect" 
href="#UsingApacheHTrace-Configuringtracingheadernames.1">Configuring tracing 
header names</a></li></ul>
 </li><li><a shape="rect" 
href="#UsingApacheHTrace-DistributedTracingInAction:UsageScenarios">Distributed 
Tracing In Action: Usage Scenarios</a>
 <ul class="toc-indentation"><li><a shape="rect" 
href="#UsingApacheHTrace-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
 #1: Client and Server with default distributed tracing 
configured</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-Example#2:ClientandServerwithnestedtrace">Example #2: 
Client and Server with nested trace</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-Example#3:ClientandServertracewithtimeline">Example 
#3: Client and Server trace with timeline</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-Example#4:ClientandServerwithannotatedtrace(key/value)">Example
 #4: Client and Server with annotated trace (key/value)</a></li><li><a 
shape="rect" 
href="#UsingApacheHTrace-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
 #5: Client and Server with parallel trace (involving thread 
pools)</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-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="#UsingApacheHTrace-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
 #7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
-</li><li><a shape="rect" 
href="#UsingApacheHTrace-DistributedTracingandJAX-WSsupport">Distributed 
Tracing and JAX-WS support</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-FutureWork">Future Work</a></li></ul>
-</div><h1 id="UsingApacheHTrace-Overview">Overview</h1><p><a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> is a 
tracing framework intended for use with distributed systems written in java. 
Since version <strong>3.1.3</strong>, Apache CXF fully supports integration 
with <a shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a>, both on 
client side and server side. This section gives a complete overview on how 
distributed tracing support is supported in JAX-RS applications built on top of 
Apache CXF.</p><h1 
id="UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing in 
Nutshell</h1><p>Distributed tracing, first described by Google in <a 
shape="rect" class="external-link" 
href="http://research.google.com/pubs/pub36356.html"; rel="nofollow">Dapper, a 
Large-Scale Distributed Systems Tracing Infrastructure</a> paper became 
increasingly important topic these days. With 
 microservices (aka SOA) gaining more and more adoption, the typical 
applications are built using dozens or even hundreds of small, distributed 
pieces. The end-to-end traceability of the requests (or any kind of work 
performed on user's behalf) is hard task to accomplish, particularly taking 
into account asyncronous or/and concurrent invocations. <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> is 
inspired by <a shape="rect" class="external-link" 
href="http://research.google.com/pubs/pub36356.html"; rel="nofollow">Dapper, a 
Large-Scale Distributed Systems Tracing Infrastructure</a> paper and 
essentially is a full-fledged distributed tracing framework.</p><p>Distributed 
tracing is additional instrumentation layer on top of new or existing 
applications. In terms of distributed tracing, <strong>span</strong> represents 
a basic unit of work. For example, executing database query is a 
<strong>span</strong>. <strong>Spans</strong> 
 are identified by a unique 128-bit ID. <strong>Spans</strong> also have other 
data, such as <strong>descriptions</strong>, 
<strong>timelines</strong>,<strong> key-value annotations</strong>, the 
<strong>ID</strong> of the <strong>span</strong> that caused them (parent), and 
<strong>process/tracer</strong> ID&#8217;s (normally IP address and process 
name). Spans are started and stopped, and they keep track of their timing 
information. Once <strong>span</strong> is created, it should be stopped at 
some point in the future. In turn, <strong>trace</strong> is a set of spans 
forming a tree-like structure. For example, if you are running a JAX-RS 
service, a trace might be formed by a <strong>PUT</strong> request and 
downstream work.</p><p>From implementation prospective, and in context of Java 
applications, <strong>spans</strong> are attached to their threads (in general, 
thread which created the <strong>span</strong> should close it). However it is 
possible to transfer <strong>spans</str
 ong> from thread to thread in order to model a complex execution flows. It is 
also possible to have many <strong>spans</strong> in the same thread, as long 
as they are properly created and closed. In the next sections we are going to 
see the examples of that.</p><p>Another two important concepts in context of 
distributed tracing are <strong>span receivers</strong> and 
<strong>samplers</strong>. Essentially, all spans (including start/stop time, 
key/value annotations, timelines, ..) should be persisted (or collected) 
somewhere. <strong>Span receiver</strong> is a collector within a process that 
is the destination of <strong>spans</strong> when a trace is running (it could 
be a console, local file, data store, ...). <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> provides 
span receivers for <a shape="rect" class="external-link" 
href="http://hbase.apache.org";>Apache HBase</a>, <a shape="rect" 
class="external-link" href="https
 ://flume.apache.org/">Apache Flume</a> and <a shape="rect" 
class="external-link" href="http://zipkin.io/"; rel="nofollow">Twitter 
Zipkin</a>. From other side, <strong>samplers</strong> allow to control the 
frequency of the tracing (all the time, never, probability driven, ...). Using 
the <strong>sampler</strong> is the way to minimize tracing overhead (or just 
amount of traces) by limiting them to particular conditions.</p><h1 
id="UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
 Tracing in Apache CXF using Apache HTrace</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. As it was just 
mentioned before, distributed tracing is an essential technique to monitor the 
application as whole, breaking the req
 uest 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://htrace.incubator.apache.org/index.html";>Apache HTrace</a> 
(<strong>4.x+</strong> release branch) only in JAX-RS 2.x applications. From 
high-level prospective, it consists of three main parts:</p><ul 
style="list-style-type: square;"><li><strong>TracerContext</strong> (injectable 
through <strong>@Context</strong> 
annotation)</li><li><strong>HTraceProvider</strong> (server-side JAX-RS 
provider) and <strong>HTraceClientProvider</strong> (client-side JAX-RS 
provider)</li><li><strong>HTraceFeature</strong> (server-side <a shape="rect" 
href="http://cxf.apache.org/";>Apache CXF</a> feature to simplify <a 
shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace
 </a> configuration and integration)</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 used internally by <strong>HTraceProvider</strong> and 
<strong>HTraceClientProvider</strong>, but are configurable. The default header 
names are declared in the TracerHeaders class:</p><ul style="list-style-type: 
square;"><li><strong>X-Span-Id</strong>: contains a current span 
ID</li></ul><p>By default, <strong>HTraceProvider</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, just 
registering the <strong>HTraceProvider</strong> on the client and 
<strong>HTraceClientProvider</strong> on the server is enough to have tracing 
context to be properly passed everywh
 ere. The only configuration part which is necessary are <strong>span 
receiver(s)</strong> and <strong>sampler</strong>(s).</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="external-link" 
href="http://localhost:8282/books"; 
rel="nofollow"><strong>http://localhost:8282</strong>/books</a>. On the server 
side integration, the description becomes a relation JAX-RS resource path 
prefixed by HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1 
id="UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring Client 
<span class="confluence-anchor-link" 
id="UsingApacheHTrace-configure.client"></span></h1><p>There are a couple of 
ways the JAX-RS client could be configured, depending on the client impleme
 ntation. <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">
+</li><li><a shape="rect" 
href="#UsingApacheHTrace-DistributedTracingApacheHTraceandJAX-WSsupport">Distributed
 Tracing Apache HTrace and JAX-WS support</a></li><li><a shape="rect" 
href="#UsingApacheHTrace-FutureWork">Future Work</a></li></ul>
+</div><h1 id="UsingApacheHTrace-Overview">Overview</h1><p><a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> is a 
tracing framework intended for use with distributed systems written in java. 
Since version <strong>3.1.3</strong>, Apache CXF fully supports integration 
with <a shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a>, both on 
client side and server side. This section gives a complete overview on how 
distributed tracing support is supported in JAX-RS applications built on top of 
Apache CXF.</p><h1 
id="UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing in 
Nutshell</h1><p>Distributed tracing, first described by Google in <a 
shape="rect" class="external-link" 
href="http://research.google.com/pubs/pub36356.html"; rel="nofollow">Dapper, a 
Large-Scale Distributed Systems Tracing Infrastructure</a> paper became 
increasingly important topic these days. With 
 microservices (aka SOA) gaining more and more adoption, the typical 
applications are built using dozens or even hundreds of small, distributed 
pieces. The end-to-end traceability of the requests (or any kind of work 
performed on user's behalf) is hard task to accomplish, particularly taking 
into account asyncronous or/and concurrent invocations. <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> is 
inspired by <a shape="rect" class="external-link" 
href="http://research.google.com/pubs/pub36356.html"; rel="nofollow">Dapper, a 
Large-Scale Distributed Systems Tracing Infrastructure</a> paper and 
essentially is a full-fledged distributed tracing framework.</p><p>Distributed 
tracing is additional instrumentation layer on top of new or existing 
applications. In terms of distributed tracing, <strong>span</strong> represents 
a basic unit of work. For example, executing database query is a 
<strong>span</strong>. <strong>Spans</strong> 
 are identified by a unique 128-bit ID. <strong>Spans</strong> also have other 
data, such as <strong>descriptions</strong>, 
<strong>timelines</strong>,<strong> key-value annotations</strong>, the 
<strong>ID</strong> of the <strong>span</strong> that caused them (parent), and 
<strong>process/tracer</strong> ID&#8217;s (normally IP address and process 
name). Spans are started and stopped, and they keep track of their timing 
information. Once <strong>span</strong> is created, it should be stopped at 
some point in the future. In turn, <strong>trace</strong> is a set of spans 
forming a tree-like structure. For example, if you are running a JAX-RS 
service, a trace might be formed by a <strong>PUT</strong> request and 
downstream work.</p><p>From implementation perspective, and in context of Java 
applications, <strong>spans</strong> are attached to their threads (in general, 
thread which created the <strong>span</strong> should close it). However it is 
possible to transfer <strong>spans</str
 ong> from thread to thread in order to model a complex execution flows. It is 
also possible to have many <strong>spans</strong> in the same thread, as long 
as they are properly created and closed. In the next sections we are going to 
see the examples of that.</p><p>Another two important concepts in context of 
distributed tracing are <strong>span receivers</strong> and 
<strong>samplers</strong>. Essentially, all spans (including start/stop time, 
key/value annotations, timelines, ..) should be persisted (or collected) 
somewhere. <strong>Span receiver</strong> is a collector within a process that 
is the destination of <strong>spans</strong> when a trace is running (it could 
be a console, local file, data store, ...). <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> provides 
span receivers for <a shape="rect" class="external-link" 
href="http://hbase.apache.org";>Apache HBase</a>, <a shape="rect" 
class="external-link" href="https
 ://flume.apache.org/">Apache Flume</a> and <a shape="rect" 
class="external-link" href="http://zipkin.io/"; rel="nofollow">Twitter 
Zipkin</a>. From other side, <strong>samplers</strong> allow to control the 
frequency of the tracing (all the time, never, probability driven, ...). Using 
the <strong>sampler</strong> is the way to minimize tracing overhead (or just 
amount of traces) by limiting them to particular conditions.</p><h1 
id="UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
 Tracing in Apache CXF using Apache HTrace</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. As it was just 
mentioned before, distributed tracing is an essential technique to monitor the 
application as whole, breaking the req
 uest 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://htrace.incubator.apache.org/index.html";>Apache HTrace</a> 
(<strong>4.x+</strong> release branch) only in JAX-RS 2.x applications. From 
high-level prospective, it consists of three main parts:</p><ul 
style="list-style-type: square;"><li><strong>TracerContext</strong> (injectable 
through <strong>@Context</strong> 
annotation)</li><li><strong>HTraceProvider</strong> (server-side JAX-RS 
provider) and <strong>HTraceClientProvider</strong> (client-side JAX-RS 
provider)</li><li><strong>HTraceFeature</strong> (server-side <a shape="rect" 
href="http://cxf.apache.org/";>Apache CXF</a> feature to simplify <a 
shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace
 </a> configuration and integration)</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 used internally by <strong>HTraceProvider</strong> and 
<strong>HTraceClientProvider</strong>, but are configurable. The default header 
names are declared in the TracerHeaders class:</p><ul style="list-style-type: 
square;"><li><strong>X-Span-Id</strong>: contains a current span 
ID</li></ul><p>By default, <strong>HTraceProvider</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, just 
registering the <strong>HTraceClientProvider</strong> on the client 
and&#160;<strong>HTraceProvider</strong> on the server is enough to have 
tracing context to be properly passed ev
 erywhere. The only configuration part which is necessary are <strong>span 
receiver(s)</strong> and <strong>sampler</strong>(s).</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="external-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="UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring Client 
<span class="confluence-anchor-link" 
id="UsingApacheHTrace-configure.client"></span></h1><p>There are a couple of 
ways the JAX-RS client could be configured, depending on the client im
 plementation. <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" 
style="font-size:12px;">final Map&lt;String, String&gt; properties = new 
HashMap&lt;String, String&gt;();
 properties.put(Tracer.SPAN_RECEIVER_CLASSES_KEY, ...);
 properties.put(Tracer.SAMPLER_CLASSES_KEY, ...);
@@ -338,7 +338,7 @@ public Collection&lt;Book&gt; getBooks()
     .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 process name <strong><span class="label label-default 
service-filter-label 
service-tag-filtered">jaxrsclient/192.168.0.100</span></strong>) and consequent 
invocation of the service on the server side (process name<strong> <span 
class="label label-default 
service-filter-label">jaxrsserver/192.168.0.100</span></strong>) is going to 
generate the following sample traces:</p><p><span 
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img 
class="confluence-embedded-image" height="250" 
src="using-apache-htrace.data/image2015-9-16%2021:9:56.png"></span></p><h1 
id="Using
 ApacheHTrace-DistributedTracingandJAX-WSsupport">Distributed Tracing 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://htrace.incubator.apache.org/index.html";>Apache HTrace</a> API 
directly (the JAX-WS integration is going to be enhanced in the nearest 
future). Essentially, from the server-side prospective the in/out 
interceptors,&#160;<strong>HTraceStartInterceptor</strong> 
and&#160;<strong>HTraceStopInterceptor </strong>respectively, should be 
configured as part of interceptor chains. The <strong>span</strong> receiver 
should be configured manually though, using <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> API, for 
example:</p><div class="code panel pdl" style="bor
 der-width: 1px;"><div class="codeContent panelContent pdl">
+</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 process name <strong><span class="label label-default 
service-filter-label 
service-tag-filtered">jaxrsclient/192.168.0.100</span></strong>) and consequent 
invocation of the service on the server side (process name<strong> <span 
class="label label-default 
service-filter-label">jaxrsserver/192.168.0.100</span></strong>) is going to 
generate the following sample traces:</p><p><span 
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img 
class="confluence-embedded-image" height="250" 
src="using-apache-htrace.data/image2015-9-16%2021:9:56.png"></span></p><h1 
id="Using
 ApacheHTrace-DistributedTracingApacheHTraceandJAX-WSsupport">Distributed 
Tracing Apache HTrace 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://htrace.incubator.apache.org/index.html";>Apache HTrace</a> API 
directly (the JAX-WS integration is going to be enhanced in the nearest 
future). Essentially, from the server-side prospective the in/out 
interceptors,&#160;<strong>HTraceStartInterceptor</strong> 
and&#160;<strong>HTraceStopInterceptor </strong>respectively, should be 
configured as part of interceptor chains. The <strong>span</strong> receiver 
should be configured manually though, using <a shape="rect" 
class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> API, 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 Map&lt;String, String&gt; properties = new 
HashMap&lt;String, String&gt;();
 final HTraceConfiguration conf = HTraceConfiguration.fromMap(properties);
 Trace.addReceiver(new StandardOutSpanReceiver(conf));

Modified: websites/production/cxf/content/docs/using-openzipkin-brave.html
==============================================================================
--- websites/production/cxf/content/docs/using-openzipkin-brave.html (original)
+++ websites/production/cxf/content/docs/using-openzipkin-brave.html Tue Jan 31 
01:47:06 2017
@@ -108,13 +108,15 @@ Apache CXF -- Using OpenZipkin Brave
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1485823591885 {padding: 0px;}
-div.rbtoc1485823591885 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1485823591885 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1485827193833 {padding: 0px;}
+div.rbtoc1485827193833 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1485827193833 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1485823591885">
-<ul class="toc-indentation"><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Overview">Overview</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
 Tracing in Apache CXF using OpenZipkin Brave</a></li></ul>
-</div><h1 id="UsingOpenZipkinBrave-Overview">Overview</h1><p><a shape="rect" 
class="external-link" href="https://github.com/openzipkin/brave"; 
rel="nofollow">OpenZipkin Brave</a> is a distributed tracing implementation 
compatible with <a shape="rect" class="external-link" href="http://zipkin.io/"; 
rel="nofollow">Twitter Zipkin</a> backend services, written in Java. For quite 
a while <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
offers a dedicated module to integrate with Apache CXF framework, namely <a 
shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave/tree/master/brave-cxf3"; 
rel="nofollow">brave-cxf3</a>. However, lately the discussion <a shape="rect" 
class="external-link" href="https://github.com/openzipkin/brave/issues/313"; 
rel="nofollow">had been initiated</a> to make this integration a part of Apache 
CXF codebase so the CXF team is going to be responsible for maintaining it. As 
such, 
 it is going to be available in upcoming <strong>3.2.0</strong> release under 
<strong>cxf-integration-tracing-brave</strong> module, with both client side 
and server side supported. This section gives a complete overview on how 
distributed tracing using&#160;<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
could be integrated into JAX-RS / JAX-WS applications built on top of Apache 
CXF.</p><p><a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
is inspired by the&#160;<a shape="rect" class="external-link" 
href="http://zipkin.io/"; rel="nofollow">Twitter Zipkin</a> and <a shape="rect" 
class="external-link" href="http://research.google.com/pubs/pub36356.html"; 
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing 
Infrastructure</a> paper and is a full-fledged distributed tracing framework. 
The section <a shape="rect" href="using-apache-htrace.html
 ">dedicated to Apache HTrace </a>has pretty good introduction into distributed 
tracing basics. However, there are a few key differences between <a 
shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> and <a 
shape="rect" class="external-link" href="https://github.com/openzipkin/brave"; 
rel="nofollow">OpenZipkin Brave</a>. In <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">Brave</a> every 
<strong>Span</strong> is associated with 128 or 64-bit long <strong>Trace 
ID</strong>, which logically groups the <strong>spans</strong> related to the 
same distributed unit of work. Within the process <strong>span</strong>s are 
collected by <strong>reporters</strong> (it could be a console, local file, 
data store, ...). <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
provides span reporters for <a shape="rect" class="external-link" h
 ref="http://zipkin.io/"; rel="nofollow">Twitter Zipkin</a> and 
<strong>java.util.logging</strong> loggers.</p><p>Under the hood 
<strong>spans</strong> are attached to their threads (in general, thread which 
created the <strong>span</strong> should close it), the same technique employed 
by other distributed tracing implementations. However, what is unique is that 
<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
distinguishes three different types of tracers:</p><ul style="list-style-type: 
square;"><li>server tracer 
(<strong>com.github.kristofa.brave.ServerTracer</strong>)</li><li>client tracer 
(<strong>com.github.kristofa.brave.ClientTracer</strong>)</li><li>local tracer 
(<strong>com.github.kristofa.brave</strong>.<strong>LocalTracer</strong>)</li></ul><p><a
 shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> integration uses 
<strong>client tracer</strong> to instantiate spans on client side (providers 
and inter
 ceptors) to demarcate send / receive cycle, <strong>server tracer</strong> on 
the server side (providers and interceptors) to demarcate receive / send cycle, 
while using <strong>local tracer</strong> for any spans instantiated within a 
process.</p><h1 
id="UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
 Tracing in Apache CXF using OpenZipkin Brave</h1></div>
+/*]]>*/</style></p><div class="toc-macro rbtoc1485827193833">
+<ul class="toc-indentation"><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Overview">Overview</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
 Tracing in Apache CXF using OpenZipkin Brave</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-ConfiguringClient">Configuring 
Client</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-ConfiguringServer">Configuring 
Server</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-DistributedTracingInAction:UsageScenarios">Distributed
 Tracing In Action: Usage Scenarios</a>
+<ul class="toc-indentation"><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
 #1: Client and Server with default distributed tracing 
configured</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#2:ClientandServerwithnestedtrace">Example 
#2: Client and Server with nested trace</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#3:ClientandServertracewithannotations">Example
 #3: Client and Server trace with annotations</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
 #4: Client and Server with binary annotations (key/value)</a></li><li><a 
shape="rect" 
href="#UsingOpenZipkinBrave-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
 #5: Client and Server with parallel trace (involving thread 
pools)</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#6:ClientandServerwithasynchronousJAX-
 RSservice(server-side)">Example #6: Client and Server with asynchronous JAX-RS 
service (server-side)</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
 #7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
+</li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-DistributedTracingwithOpenZipkinBraveandJAX-WSsupport">Distributed
 Tracing with OpenZipkin Brave and JAX-WS support</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating from 
brave-cxf3</a></li></ul>
+</div><h1 id="UsingOpenZipkinBrave-Overview">Overview</h1><p><a shape="rect" 
class="external-link" href="https://github.com/openzipkin/brave"; 
rel="nofollow">OpenZipkin Brave</a> is a distributed tracing implementation 
compatible with <a shape="rect" class="external-link" href="http://zipkin.io/"; 
rel="nofollow">Twitter Zipkin</a> backend services, written in Java. For quite 
a while <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
offers a dedicated module to integrate with Apache CXF framework, namely <a 
shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave/tree/master/brave-cxf3"; 
rel="nofollow">brave-cxf3</a>. However, lately the discussion <a shape="rect" 
class="external-link" href="https://github.com/openzipkin/brave/issues/313"; 
rel="nofollow">had been initiated</a> to make this integration a part of Apache 
CXF codebase so the CXF team is going to be responsible for maintaining it. As 
such, 
 it is going to be available in upcoming <strong>3.2.0</strong> release under 
<strong>cxf-integration-tracing-brave</strong> module, with both client side 
and server side supported. This section gives a complete overview on how 
distributed tracing using&#160;<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
could be integrated into JAX-RS / JAX-WS applications built on top of Apache 
CXF.</p><p><a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
is inspired by the&#160;<a shape="rect" class="external-link" 
href="http://zipkin.io/"; rel="nofollow">Twitter Zipkin</a> and <a shape="rect" 
class="external-link" href="http://research.google.com/pubs/pub36356.html"; 
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing 
Infrastructure</a> paper and is a full-fledged distributed tracing framework. 
The section <a shape="rect" href="using-apache-htrace.html
 ">dedicated to Apache HTrace </a>has pretty good introduction into distributed 
tracing basics. However, there are a few key differences between <a 
shape="rect" class="external-link" 
href="http://htrace.incubator.apache.org/index.html";>Apache HTrace</a> and <a 
shape="rect" class="external-link" href="https://github.com/openzipkin/brave"; 
rel="nofollow">OpenZipkin Brave</a>. In <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">Brave</a> every 
<strong>Span</strong> is associated with 128 or 64-bit long <strong>Trace 
ID</strong>, which logically groups the <strong>spans</strong> related to the 
same distributed unit of work. Within the process <strong>span</strong>s are 
collected by <strong>reporters</strong> (it could be a console, local file, 
data store, ...). <a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
provides span reporters for <a shape="rect" class="external-link" h
 ref="http://zipkin.io/"; rel="nofollow">Twitter Zipkin</a> and 
<strong>java.util.logging</strong> loggers.</p><p>Under the hood 
<strong>spans</strong> are attached to their threads (in general, thread which 
created the <strong>span</strong> should close it), the same technique employed 
by other distributed tracing implementations. However, what is unique is that 
<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
distinguishes three different types of tracers:</p><ul style="list-style-type: 
square;"><li>server tracer 
(<strong>com.github.kristofa.brave.ServerTracer</strong>)</li><li>client tracer 
(<strong>com.github.kristofa.brave.ClientTracer</strong>)</li><li>local tracer 
(<strong>com.github.kristofa.brave</strong>.<strong>LocalTracer</strong>)</li></ul><p><a
 shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> integration uses 
<strong>client tracer</strong> to instantiate spans on client side (providers 
and inter
 ceptors) to demarcate send / receive cycle, <strong>server tracer</strong> on 
the server side (providers and interceptors) to demarcate receive / send cycle, 
while using <strong>local tracer</strong> for any spans instantiated within a 
process.</p><h1 
id="UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
 Tracing in Apache CXF using OpenZipkin Brave</h1><p>The current integration of 
distributed tracing in <a shape="rect" href="http://cxf.apache.org/";>Apache 
CXF</a> supports&#160;<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
(<strong>3.16+</strong> release branch) in JAX-RS 2.x+ and JAX-WS applications, 
including the applications deploying in <a shape="rect" class="external-link" 
href="https://www.osgi.org/"; rel="nofollow">OSGi</a> containers. From 
high-level perspective,&#160;JAX-RS 2.x+ integration consists of three main 
parts:</p><ul><li><strong>TracerContext</strong> (injectabl
 e through <strong>@Context</strong> 
annotation)</li><li><strong>BraveProvider</strong> (server-side JAX-RS 
provider) and <strong>BraveClientProvider</strong> (client-side JAX-RS 
provider)</li><li><strong>BraveFeature</strong> (server-side&#160;JAX-RS 
feature to simplify&#160;<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
configuration and integration)</li></ul><p>Similarly, from high-level 
perspective,&#160;JAX-WS integration includes:</p><ul style="list-style-type: 
square;"><li><strong>BraveStartInterceptor</strong> / 
<strong>BraveStopInterceptor</strong> / <strong>BraveFeature&#160;</strong><a 
shape="rect" href="http://cxf.apache.org/";>Apache CXF</a> feature (server-side 
JAX-WS support)</li><li><strong>BraveClientStartInterceptor</strong> / 
<strong>BraveClientStopInterceptor</strong> / 
<strong>BraveClientFeature&#160;</strong><a shape="rect" 
href="http://cxf.apache.org/";>Apache CXF</a> feature (client-side JAX-W
 S 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 used internally by 
<a shape="rect" class="external-link" 
href="https://github.com/openzipkin/brave"; rel="nofollow">OpenZipkin Brave</a> 
and are not configurable at the moment. The header names are declared in 
the&#160;<strong>BraveHttpHeaders</strong> class and at the moment 
include:</p><ul style="list-style-type: 
square;"><li><strong>X-B3-TraceId</strong>: 128 or 64-bit trace 
ID</li><li><strong>X-B3-SpanId</strong>: 64-bit span 
ID</li><li><strong>X-B3-ParentSpanId</strong>: 64-bit parent span 
ID</li><li><p><strong>X-B3-Sampled</strong>: "1" means report this span to the 
tracing system, "0" means do not</p></li></ul><p>By default, 
<strong>BraveClientProvider</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>BraveClientProvider</strong> on the client and 
<strong>BraveProvider</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).</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="external-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 HT
 TP method, f.e.: <strong>GET books, POST book/123</strong></p><h1 
id="UsingOpenZipkinBrave-ConfiguringClient">Configuring Client</h1><p>// 
TODO</p><h1 id="UsingOpenZipkinBrave-ConfiguringServer">Configuring 
Server</h1><p>// TODO</p><h1 
id="UsingOpenZipkinBrave-DistributedTracingInAction:UsageScenarios">Distributed 
Tracing In Action: Usage Scenarios</h1><h2 
id="UsingOpenZipkinBrave-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
 #1: Client and Server with default distributed tracing configured</h2><h2 
id="UsingOpenZipkinBrave-Example#2:ClientandServerwithnestedtrace">Example #2: 
Client and Server with nested trace</h2><h2 
id="UsingOpenZipkinBrave-Example#3:ClientandServertracewithannotations">Example 
#3: Client and Server trace with annotations</h2><h2 
id="UsingOpenZipkinBrave-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
 #4: Client and Server with binary annotations (key/value)</h2><h2 
id="UsingOpenZipkinBrave-Example#5:ClientandServerw
 ithparalleltrace(involvingthreadpools)">Example #5: Client and Server with 
parallel trace (involving thread pools)</h2><h2 
id="UsingOpenZipkinBrave-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Example
 #6: Client and Server with asynchronous JAX-RS service (server-side)</h2><h2 
id="UsingOpenZipkinBrave-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
 #7: Client and Server with asynchronous invocation (client-side)</h2><h1 
id="UsingOpenZipkinBrave-DistributedTracingwithOpenZipkinBraveandJAX-WSsupport">Distributed
 Tracing with OpenZipkin Brave and JAX-WS support</h1><p>// TODO</p><h1 
id="UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating from 
brave-cxf3</h1><p>// TODO</p></div>
            </div>
            <!-- Content -->
          </td>


Reply via email to