cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1038591 - in /websites/production/cxf/content: cache/docs.pageCache docs/using-openzipkin-brave.html
Date Sat, 05 Jan 2019 19:57:27 GMT
Author: buildbot
Date: Sat Jan  5 19:57:27 2019
New Revision: 1038591

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 Sat Jan  5 19:57:27 2019
@@ -119,16 +119,16 @@ Apache CXF -- Using OpenZipkin Brave
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1524513377668 {padding: 0px;}
-div.rbtoc1524513377668 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1524513377668 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1546718208744 {padding: 0px;}
+div.rbtoc1546718208744 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1546718208744 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1524513377668">
+/*]]>*/</style></p><div class="toc-macro rbtoc1546718208744">
 <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>
+</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><li><a shape="rect" href="#UsingOpenZipkinBrave-Usingnon-JAX-RSclients">Using
non-JAX-RS clients</a></li><li><a shape="rect" href="#UsingOpenZipkinBrave-AccessingBraveAPIs">Accessing
Brave APIs</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> (<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
+<pre class="brush: java; gutter: false; theme: Default">// Configure the spans transport
sender
 final Sender sender = ...; 
 
 /**
@@ -151,7 +151,7 @@ Response response = WebClient
 
 </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;">//
Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default">// Configure the spans transport
sender
 final Sender sender = ...; 
 
 /**
@@ -176,7 +176,7 @@ final Response response = client
     .accept(MediaType.APPLICATION_JSON)
     .get();</pre>
 </div></div><h1 id="UsingOpenZipkinBrave-configuringserverConfiguringServer"><span
class="confluence-anchor-link" id="UsingOpenZipkinBrave-configuringserver"></span>Configuring
Server</h1><p>Server configuration is a bit simpler than the client one thanks
to the feature class available, <strong>BraveFeature</strong>. Depending on the
way the&#160;<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("/")
+<pre class="brush: java; gutter: false; theme: Default">@ApplicationPath("/")
 public class CatalogApplication extends Application {
     @Override
     public Set&lt;Object&gt; getSingletons() {
@@ -204,7 +204,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;">//
Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default">// Configure the spans transport
sender
 final Sender sender = ...; 
 
 /**
@@ -227,7 +227,7 @@ return factory.create();
 
 </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="UsingOpenZipkinBrave-DistributedTracingInAction:UsageScenarios">Distributed Tracing
In Action: Usage Scenarios</h1><p>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="using-openzipkin-brave.html"><span class="confluence-link"><span class="confluence-link">Configuring
Client</span></span></a><span class="confluence-link">&#160;</span>
and <a shape="rect" href="using-openzipkin-brave.html"><span class="confluence-link">Configuring
Server</span></a> sections above).</p><h2 id="UsingOpenZipkinBra
 ve-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>BraveClientProvider</strong>&#160; and <strong><strong>Brave</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 } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks() {
     return Arrays.asList(
@@ -235,13 +235,13 @@ public Collection&lt;Book&gt; 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:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="150"
src="using-openzipkin-brave.data/image2017-2-6%2020:16:19.png"></span></p><p>&#160;</p><p>Please
notice that client and server traces are collapsed under one trace with client send / receive,
and server send / receive demarcation as is seen in details<span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="400"
src="using-openzipkin-brave.data/image2017-2-6%2020:18:51.png"></span></p><h2
id="UsingOpenZipkinBrave-Example#2:ClientandServerwithnestedtrace">Example #2: Client and
Server with nested trace</h2><p>In th
 is 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 } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks(@Context final TracerContext tracer) throws
Exception {
     try(final TraceScope scope = tracer.startSpan("Calling External System")) {
@@ -254,7 +254,7 @@ public Collection&lt;Book&gt; getBooks(@
     }
 }</pre>
 </div></div><p class="label label-default service-filter-label">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:</p><p class="label label-default service-filter-label"><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image"
width="900" src="using-openzipkin-brave.data/image2017-2-6%2020:21:46.png"></span></p><h2
id="UsingOpenZipkinBrave-Example#3:ClientandServertracewithannotations">Example #3: Client
and Server trace with annotations</h2><p>In this example server-side implementat
 ion 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 } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks(@Context final TracerContext tracer) throws
Exception {
     tracer.timeline("Preparing Books");
@@ -266,7 +266,7 @@ public Collection&lt;Book&gt; getBooks(@
     );
 }</pre>
 </div></div><p class="label label-default service-filter-label">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:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" width="900"
src="using-openzipkin-brave.data/image2017-2-6-20:56:27.png"></span></p><h2
id="UsingOpenZipkinBrave-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="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">@Produces(
{ MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks(@Context final TracerContext tracer) throws
Exception {
     final Collection&lt;Book&gt; books = Arrays.asList(
@@ -277,7 +277,7 @@ public Collection&lt;Book&gt; getBooks(@
     return books;
 }</pre>
 </div></div><p class="label label-default service-filter-label service-tag-filtered">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:</p><p class="label
label-default service-filter-label service-tag-filtered"><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="250"
src="using-openzipkin-brave.data/image2017-2-6%2020:49:43.png"></span></p><h2
id="UsingOpenZipkinBrave-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 } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks(@Context final TracerContext tracer) throws
Exception {
     final Future&lt;Book&gt; book1 = executor.submit(
@@ -307,7 +307,7 @@ public Collection&lt;Book&gt; 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:</p><p><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" width="900" src="using-openzipkin-brave.data/image2017-2-6-21:41:1.png"></span></p><h2
id="UsingOpenZipkinBrave-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 process
 ed 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 } )
+<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&lt;Future&lt;Void&gt;&gt;() {
@@ -332,7 +332,7 @@ public void getBooks(@Suspended final As
     });
 }</pre>
 </div></div><p class="label label-default service-filter-label service-tag-filtered">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:</p><p class="label label-default service-filter-label
service-tag-filtered"><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image" width="900" src="using-openzipkin-brave.data/image2017-2-6-21:46:48.png"></span></p><h2
id="UsingOpenZipkinBrave-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 } )
+<pre class="brush: java; gutter: false; theme: Default">@Produces( { MediaType.APPLICATION_JSON
} )
 @GET
 public Collection&lt;Book&gt; getBooks() {
     return Arrays.asList(
@@ -340,14 +340,14 @@ public Collection&lt;Book&gt; getBooks()
     );
 }</pre>
 </div></div><p>While the JAX-RS client&#160;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&lt;Response&gt; future = client
+<pre class="brush: java; gutter: false; theme: Default">final Future&lt;Response&gt;
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:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" width="900"
src="using-openzipkin-brave.data/image2017-2-6-21:6:56.png"></span></p><h1
id="UsingOpenZipkinBrave-Distribut
 edTracingwithOpenZipkinBraveandJAX-WSsupport">Distributed Tracing with OpenZipkin Brave
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&#160;<a shape="rect"
class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a> API directly (the JAX-WS integration is going to be enhanced in the future).
Essentially, from the server-side prospective the in/out interceptors, <strong>BraveStartInterceptor</strong>
and <strong>BraveStopInterceptor </strong>respectively, should be configured as
part of interceptor chains, either manually or using <strong>BraveFeature</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;">//
Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default">// Configure the spans transport
sender
 final Sender sender = ...; 
 
 /**
@@ -371,7 +371,7 @@ sf.create();
 
 </pre>
 </div></div><p>Similarly to the server-side, client-side needs own set
of out/in interceptors, <strong>BraveClientStartInterceptor</strong> and <strong>BraveClientStopInterceptor</strong>
(or <strong>BraveClientFeature</strong>). Please notice the difference from server-side:&#160;
<strong>BraveClientStartInterceptor</strong> becomes out-interceptor while <strong>BraveClientStopInterceptor</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;">//
Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default">// Configure the spans transport
sender
 final Sender sender = ...; 
 
 /**
@@ -395,7 +395,7 @@ sf.create();
 
 </pre>
 </div></div><h1 id="UsingOpenZipkinBrave-DistributedTracingwithOpenZipkinBraveandOSGi">Distributed
Tracing with OpenZipkin Brave and OSGi</h1><p><a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> could
be deployed into <strong>OSGi</strong> container and as such, distributed tracing
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/blob/180d0fcc5e0d061f339e1a3cb32ec53a3ab32b97/distribution/src/main/release/samples/jaxws_tracing_brave_osgi/README.txt"
rel="nofollow">jax_ws_tracing_brave_osgi</a> sample project, but here is the typical
<strong>OSGi</strong>&#160; Blueprint snippet:</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;">&lt;?xml
version="1.0" encoding="UTF-8"?&gt;
+<pre class="brush: java; gutter: false; theme: Default">&lt;?xml version="1.0"
encoding="UTF-8"?&gt;
 &lt;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"
@@ -438,19 +438,19 @@ sf.create();
     &lt;/jaxws:endpoint&gt;
 &lt;/blueprint&gt;</pre>
 </div></div><h1 id="UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating
from brave-cxf3</h1><p>The migration path from <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave/tree/master/brave-cxf3" rel="nofollow">OpenZipkin
Brave / CXF</a> to <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a>
integration is pretty straightforward and essentially boils down to using JAX-RS ( <strong>BraveFeature</strong>
for server side / <strong>BraveClientFeature</strong>&#160;for client side
(imported from <strong>org.apache.cxf.tracing.brave.jaxrs</strong> package), 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;">JAXRSServerFactoryBean
serverFactory = new JAXRSServerFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default">JAXRSServerFactoryBean serverFactory
= new JAXRSServerFactoryBean();
 serverFactory.setServiceBeans(new RestFooService());
 serverFactory.setAddress("http://localhost:9001/");
 serverFactory.getFeatures().add(new BraveFeature(brave));
 serverFactory.create();</pre>
 </div></div><p>Although you may continue to use <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> API
directly, for the server-side it is preferable to inject <strong>@Context TracerContext&#160;</strong>
into your JAX-RS services in order to interface with the tracer.</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;">JAXRSClientFactoryBean
clientFactory = new JAXRSClientFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default">JAXRSClientFactoryBean clientFactory
= new JAXRSClientFactoryBean();
 clientFactory.setAddress("http://localhost:9001/");
 clientFactory.setServiceClass(FooService.class);
 clientFactory.getFeatures().add(new BraveClientFeature(brave));
 FooService client = (FooService) clientFactory.create()</pre>
 </div></div><p>&#160;</p><p>Similarly for JAX-WS <strong>BraveFeature</strong>
for server side / <strong>BraveClientFeature</strong>&#160;for client side
(imported from <strong>org.apache.cxf.tracing.brave </strong>package), 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;">JaxWsServerFactoryBean
serverFactory = new JaxWsServerFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default">JaxWsServerFactoryBean serverFactory
= new JaxWsServerFactoryBean();
 serverFactory.setAddress("http://localhost:9000/test");
 serverFactory.setServiceClass(FooService.class);
 serverFactory.setServiceBean(fooServiceImplementation);
@@ -458,13 +458,13 @@ serverFactory.getFeatures().add(new Brav
 
 serverFactory.create();</pre>
 </div></div><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;">JAXRSClientFactoryBean
clientFactory = new JAXRSClientFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default">JAXRSClientFactoryBean clientFactory
= new JAXRSClientFactoryBean();
 clientFactory.setAddress("http://localhost:9001/");
 clientFactory.setServiceClass(FooService.class);
 clientFactory.getFeatures().add(new BraveClientFeature(brave));
 FooService client = (FooService) clientFactory.create();</pre>
 </div></div><h1 id="UsingOpenZipkinBrave-SpringXML-Configuration">Spring
XML-Configuration</h1><p>If your project uses classic Spring XML-Configuration,
you should consider using <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave/tree/master/spring-beans"
rel="nofollow">brave-spring-beans</a>. The factory beans allow to create the config
like this:</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;">&lt;bean
id="braveFeature" class="org.apache.cxf.tracing.brave.BraveFeature"&gt;&lt;!-- JAX-WS
server feature --&gt;
+<pre class="brush: xml; gutter: false; theme: Default">&lt;bean id="braveFeature"
class="org.apache.cxf.tracing.brave.BraveFeature"&gt;&lt;!-- JAX-WS server feature
--&gt;
    &lt;constructor-arg ref="httpTracing" /&gt;
 &lt;/bean&gt;
 
@@ -493,7 +493,52 @@ FooService client = (FooService) clientF
       &lt;bean class="org.apache.cxf.tracing.brave.HttpServerSpanParser" /&gt;
    &lt;/property&gt;
 &lt;/bean&gt;</pre>
-</div></div></div>
+</div></div><h1 id="UsingOpenZipkinBrave-Usingnon-JAX-RSclients">Using
non-JAX-RS clients</h1><p>The&#160; <a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a>&#160; uses native <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> capabilities so the existing instrumentations
for different HTTP clients work as expected. The usage of only JAX-RS client is not required.
For example, the following snippet demonstrates the usage of traceble <a shape="rect" class="external-link"
href="http://square.github.io/okhttp/" rel="nofollow">OkHttp</a> client&#160;
to call JAX-RS resources, backed by <a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> .</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">final Tracing brave = Tracing
+    .newBuilder()
+    .localServiceName("web-client")
+    .reporter(AsyncReporter.builder(sender).build())
+    .traceSampler(Sampler.ALWAYS_SAMPLE) /* or any other Sampler */
+    .build();
+
+final OkHttpClient client = new OkHttpClient();
+final Call.Factory factory = TracingCallFactory.create(brave, client);
+            
+final Request request = new Request.Builder()
+    .url("http://localhost:9000/catalog")
+    .header("Accept", "application/json")
+    .build();
+
+try (final Response response = factory.newCall(request).execute()) {
+    // Do something with response.body()
+}</pre>
+</div></div><h1 id="UsingOpenZipkinBrave-AccessingBraveAPIs">Accessing
Brave APIs</h1><p>The <a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a>&#160; abstracts as much of the tracer-specific APIs behind <strong>TracerContext</strong>
as possible. However, sometimes there is a need to get access to <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> APIs
in order to leverages the rich set of available instrumentations. To make it possible, <strong>TracerContext</strong>
has a dedicated <strong>unwrap</strong> method which returns underlying <strong>HttpTracing</strong>,
<strong>Tracer</strong> or <strong>Tracing</strong> instances. The
snippet below shows off how to use this API and use <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> instrumentation
for <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave/tree/maste
 r/instrumentation/httpclient" rel="nofollow">Apache HttpClient</a>.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: java; gutter: false; theme: Default">@GET
+@Path("/search")
+@Produces(MediaType.APPLICATION_JSON)
+public JsonObject search(@QueryParam("q") final String query, @Context final TracerContext
tracing) throws Exception {
+    final CloseableHttpClient httpclient = TracingHttpClientBuilder
+        .create(tracing.unwrap(HttpTracing.class))
+        .build();
+    
+    try {
+        final URI uri = new URIBuilder("https://www.googleapis.com/books/v1/volumes")
+            .setParameter("q", query)
+            .build();
+            
+        final HttpGet request = new HttpGet(uri);
+        request.setHeader("Accept", "application/json");
+            
+        final HttpResponse response = httpclient.execute(request);
+        final String data = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8);
+        try (final StringReader reader = new StringReader(data)) {
+            return Json.createReader(reader).readObject();
+        }
+    } finally {
+        httpclient.close();
+    }
+}</pre>
+</div></div><p>The usage of tracer-specific APIs is not generally advisable
(because of portability reasons) but in case there are no other options available, it is available.</p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message