Author: buildbot
Date: Thu Sep 14 00:59:17 2017
New Revision: 1018132

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    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-openzipkin-brave.html
==============================================================================
--- websites/production/cxf/content/docs/using-openzipkin-brave.html (original)
+++ websites/production/cxf/content/docs/using-openzipkin-brave.html Thu Sep 14 
00:59:17 2017
@@ -32,9 +32,9 @@
 <link type="text/css" rel="stylesheet" 
href="/resources/highlighter/styles/shThemeCXF.css">
 
 <script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.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();
@@ -119,15 +119,15 @@ Apache CXF -- Using OpenZipkin Brave
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505314977099 {padding: 0px;}
-div.rbtoc1505314977099 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505314977099 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505350715270 {padding: 0px;}
+div.rbtoc1505350715270 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505350715270 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1505314977099">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505350715270">
 <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-configuringclientConfiguringClient">Configuring 
Client</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-configuringserverConfiguringServer">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-DistributedTracingwithOpenZipkinBraveandOSGi">Distributed
 Tracing with OpenZipkin Brave and OSGi</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating from 
brave-cxf3</a></li><li><a shape="rect" 
href="#UsingOpenZipkinBrave-SpringXML-Configuration">Spring 
XML-Configuration</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 <strong>since 3.2.0/3.1.12</strong> releases 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.ht
 ml">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"
  href="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 int
 erceptors) 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>4.3.x+</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> (inject
 able 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 JA
 X-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 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 invocatio
 n. 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
  HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1 
id="UsingOpenZipkinBrave-configuringclientConfiguringClient"><span 
class="confluence-anchor-link" 
id="UsingOpenZipkinBrave-configuringclient"></span>Configuring 
Client</h1><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">
+</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 <strong>since 3.2.0/3.1.12</strong> releases 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> 
(<strong>4.3.x+</strong>) 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" hr
 ef="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="r
 ect" class="external-link" href="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.<a shape="rect" 
href="http://cxf.apache.org/";> Apache CXF</a> integration uses&#160; 
<strong>HttpTracing </strong>(part of Brave HTTP instrumentation) to 
instantiate spans on client side (providers and interceptors) to demarcate send 
/ receive cycle as well on the server side (providers and interceptors) to 
demarcate receive / send cycle, while using regular <strong>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="r
 ect" 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>4.3.x+</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> (injectable 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-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 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 
<strong>B3Propagation </str
 ong>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><li><strong>X-B3-Flags</strong>: "1" 
implies sampled and is a request to override collection-tier sampling 
policy</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 o
 nly 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 HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1 
id="UsingOpenZipkinBrave-configuringclientConfiguringClient"><span 
class="confluence-anchor-link" 
id="UsingOpenZipkinBrave-configuringclient"></span>Configuring 
Client</h1><p>There are a couple of ways the JAX-RS client could be configured, 
depending on the client implementat
 ion. <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;">// Configure the spans transport sender
 final Sender sender = ...; 
 


Reply via email to