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 Wed Sep 13
15:05:52 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/shBrushJava.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.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>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -119,16 +119,16 @@ Apache CXF -- Using OpenZipkin Brave
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505311200759 {padding: 0px;}
-div.rbtoc1505311200759 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505311200759 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505314977099 {padding: 0px;}
+div.rbtoc1505314977099 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505314977099 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1505311200759">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505314977099">
<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 <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 <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 <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, 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 JAX-RS
feature to simplify <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, JAX-WS integration includes:</p><ul style="list-style-type:
square;"><li><strong>BraveStartInterceptor</strong> /
<strong>BraveStopInterceptor</strong> / <strong>BraveFeature </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 </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 <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">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// 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 <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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@ApplicationPath("/")
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@ApplicationPath("/")
public class CatalogApplication extends Application {
@Override
public Set<Object> 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// 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"> </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>  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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks() {
return Arrays.asList(
@@ -235,13 +235,13 @@ public Collection<Book> getBooks()
);
}</pre>
</div></div><p>The client is as simple as that:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">final Response response = client
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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> </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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
try(final TraceScope scope = tracer.startSpan("Calling External System")) {
@@ -254,7 +254,7 @@ public Collection<Book> 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
tracer.timeline("Preparing Books");
@@ -266,7 +266,7 @@ public Collection<Book> 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%2020: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 unchang
ed.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
final Collection<Book> books = Arrays.asList(
@@ -277,7 +277,7 @@ public Collection<Book> 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks(@Context final TracerContext tracer)
throws Exception {
final Future<Book> book1 = executor.submit(
@@ -307,7 +307,7 @@ public Collection<Book> getBooks(@
return Arrays.asList(book1.get(), book2.get());
}</pre>
</div></div><p>The actual invocation of the request by the client (with
service name <strong>tracer-<span class="label label-default
service-filter-label service-tag-filtered">client</span></strong>) and
consequent invocation of the service on the server side (process name<strong>
tracer-<span class="label label-default
service-filter-label">server</span></strong>) is going to generate the
following sample traces:</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%2021: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 proce
ssed 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public void getBooks(@Suspended final AsyncResponse response, @Context final
TracerContext tracer) throws Exception {
tracer.continueSpan(new Traceable<Future<Void>>() {
@@ -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%2021: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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Produces( { MediaType.APPLICATION_JSON } )
@GET
public Collection<Book> getBooks() {
return Arrays.asList(
@@ -340,14 +340,14 @@ public Collection<Book> getBooks()
);
}</pre>
</div></div><p>While the JAX-RS client implementation is going to perform
the asynchronous invocation:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">final Future<Response> future = client
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">final Future<Response> future = client
.target("http://localhost:8282/books")
.request()
.accept(MediaType.APPLICATION_JSON)
.async()
.get();</pre>
</div></div><p>In this respect, there is no difference from the caller
prospective however a bit more work is going under the hood to transfer the
active tracing span from JAX-RS client request filter to client response filter
as in general those are executed in different threads (similarly to server-side
asynchronous JAX-RS resource invocation). The actual invocation of the request
by the client (with service name <strong>tracer-<span class="label
label-default service-filter-label
service-tag-filtered">client</span></strong>) and consequent invocation of the
service on the server side (service name<strong> tracer-<span class="label
label-default service-filter-label">server</span></strong>) is going to
generate the following sample traces:</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%2021:6:56.png"></span></p><h1
id="UsingOpenZipkinBrave-Distrib
utedTracingwithOpenZipkinBraveandJAX-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 <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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// 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:  <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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Configure the spans transport sender
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// 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>  Blueprint snippet:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cxf="http://cxf.apache.org/blueprint/core"
@@ -438,19 +438,19 @@ sf.create();
</jaxws:endpoint>
</blueprint></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> 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">JAXRSServerFactoryBean serverFactory = new
JAXRSServerFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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 </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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">JAXRSClientFactoryBean clientFactory = new
JAXRSClientFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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> </p><p>Similarly for JAX-WS <strong>BraveFeature</strong>
for server side / <strong>BraveClientFeature</strong> 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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">JaxWsServerFactoryBean serverFactory = new
JaxWsServerFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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: bash; gutter: false; theme: Confluence"
style="font-size:12px;">JAXRSClientFactoryBean clientFactory = new
JAXRSClientFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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: Confluence"
style="font-size:12px;"><bean id="braveFeature"
class="org.apache.cxf.tracing.brave.BraveFeature"><!-- JAX-WS server
feature -->
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><bean id="braveFeature"
class="org.apache.cxf.tracing.brave.BraveFeature"><!-- JAX-WS server
feature -->
<constructor-arg ref="httpTracing" />
</bean>
Modified: websites/production/cxf/content/docs/using-the-jmsconfigfeature.html
==============================================================================
--- websites/production/cxf/content/docs/using-the-jmsconfigfeature.html
(original)
+++ websites/production/cxf/content/docs/using-the-jmsconfigfeature.html Wed
Sep 13 15:05:52 2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ Apache CXF -- Using the JMSConfigFeature
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><p>Standard JMS transport configuration in CXF is
done by defining a JMSConduit or JMSDestination. There is however an easier
configuration option more conformant to Spring dependency injection.
Additionally the new configuration offers many more options. For example it is
not necessary anymore to use JNDI to resolve the connection factory. Instead it
can be defined in the Spring configuration.</p><p>The following example configs
use the <a shape="rect" class="external-link"
href="http://static.springframework.org/spring/docs/2.5.x/reference/beans.html"
rel="nofollow">p-namespace</a> from spring 2.5 but the old spring bean style is
also possible.</p><p>Inside a features element the JMSConfigFeature can be
defined.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><jaxws:client id="CustomerService"
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:client id="CustomerService"
xmlns:customer="http://customerservice.example.com/"
serviceName="customer:CustomerServiceService"
endpointName="customer:CustomerServiceEndpoint" address="jms://"
@@ -131,7 +131,7 @@ Apache CXF -- Using the JMSConfigFeature
</jaxws:client>
</pre>
</div></div><p>In the above example it references a bean "jmsConfig" where the
whole configuration for the JMS transport can be done.</p><p>A jaxws Endpoint
can be defined in the same way:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><jaxws:endpoint
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:endpoint
xmlns:customer="http://customerservice.example.com/"
id="CustomerService"
address="jms://"
@@ -145,13 +145,13 @@ Apache CXF -- Using the JMSConfigFeature
</jaxws:endpoint>
</pre>
</div></div><p>The JMSConfiguration bean needs at least a reference to a
conncection factory and a target destination.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"
p:connectionFactory-ref="jmsConnectionFactory"
p:targetDestination="test.cxf.jmstransport.queue"
/>
</pre>
</div></div><p>If your ConnectionFactory does not cache connections you should
wrap it in a spring SingleConnectionFactory. This is necessary because the JMS
Transport creates a new connection for each message and the
SingleConnectionFactory is needed to cache this connection.</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><bean id="jmsConnectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="jmsConnectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
<property name="targetConnectionFactory">
<bean
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL"
value="tcp://localhost:61616" />
@@ -160,7 +160,7 @@ Apache CXF -- Using the JMSConfigFeature
</bean>
</pre>
</div></div><h2
id="UsingtheJMSConfigFeature-UsingJMSConfigurationfromJava">Using
JMSConfiguration from Java</h2><p>To do this from Java, you need to initialize
a JMSConfiguration object, then store a reference to it in a JMSConfigFeature,
and then add that to the features in the server factory. The code that follows
is fragmentary. Note that you can't use query parameters in the endpoint URI
that you set in the server factory, all the configuration has to be in the
JMSConfiguration object.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">public static JMSConfiguration
newJMSConfiguration(String taskId, String jmsBrokerUrl) {
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public static JMSConfiguration
newJMSConfiguration(String taskId, String jmsBrokerUrl) {
String destinationUri = "jms:queue:" + taskId;
JMSConfiguration conf = new JMSConfiguration();
conf.setRequestURI(destinationUri);
Modified: websites/production/cxf/content/docs/validationfeature.html
==============================================================================
--- websites/production/cxf/content/docs/validationfeature.html (original)
+++ websites/production/cxf/content/docs/validationfeature.html Wed Sep 13
15:05:52 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/shBrushJava.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.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>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -119,11 +119,11 @@ Apache CXF -- ValidationFeature
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><h1
id="ValidationFeature-BeanValidationFeature">Bean Validation
Feature</h1><p> </p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505311217461 {padding: 0px;}
-div.rbtoc1505311217461 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505311217461 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505314841762 {padding: 0px;}
+div.rbtoc1505314841762 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505314841762 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1505311217461">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505314841762">
<ul class="toc-indentation"><li><a shape="rect"
href="#ValidationFeature-BeanValidationFeature">Bean Validation
Feature</a></li><li><a shape="rect"
href="#ValidationFeature-Introduction">Introduction</a></li><li><a shape="rect"
href="#ValidationFeature-Dependencies">Dependencies</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#ValidationFeature-UsingHibernateValidatorasbeanvalidationprovider">Using
Hibernate Validator as bean validation provider</a></li><li><a shape="rect"
href="#ValidationFeature-UsingApacheBValasbeanvalidationprovider">Using Apache
BVal as bean validation provider</a></li></ul>
</li><li><a shape="rect"
href="#ValidationFeature-CommonBeanValidation1.1Interceptors">Common Bean
Validation 1.1 Interceptors</a>
@@ -136,7 +136,7 @@ div.rbtoc1505311217461 li {margin-left:
<ul class="toc-indentation"><li><a shape="rect"
href="#ValidationFeature-Validatingsimpleinputparameters">Validating simple
input parameters</a></li><li><a shape="rect"
href="#ValidationFeature-Validatingcomplexinputparameters">Validating complex
input parameters</a></li><li><a shape="rect"
href="#ValidationFeature-Validatingreturnvalues(non-Response)">Validating
return values (non-Response)</a></li><li><a shape="rect"
href="#ValidationFeature-Validatingreturnvalues(Response)">Validating return
values (Response)</a></li></ul>
</li><li><a shape="rect"
href="#ValidationFeature-BeanValidationandSchemaValidation">Bean Validation and
Schema Validation</a></li></ul>
</div><h1 id="ValidationFeature-Introduction">Introduction</h1><p>Bean
Validation 1.1 (JSR-349), an evolution of Bean Validation 1.0 (JSR-303),
introduces declarative constraints (based on Java annotations) to define the
expectations for:</p><ul class="alternate"><li>properties of Java
Beans</li><li>method and constructor parameters</li><li>method return
values</li></ul><p>For example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">public class Person {
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class Person {
@NotNull private String firstName;
@NotNull private String lastName;
@Valid @NotNull private Person boss;
@@ -147,7 +147,7 @@ div.rbtoc1505311217461 li {margin-left:
}
</pre>
</div></div><p>Bean Validation API has been part of JPA 2.0 (JSR-317) and has
proven to be successful and very useful, helping developers to delegate routine
validation tasks to the solid, very extensible framework. It is very easy to
create own constraints, including complex cross-field ones.</p><h1
id="ValidationFeature-Dependencies">Dependencies</h1><p>Bean Validation support
in Apache CXF is implementation-independent and is built solely using Bean
Validation API. The required dependencies are:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><dependency>
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Final</version>
@@ -166,7 +166,7 @@ div.rbtoc1505311217461 li {margin-left:
</dependency>
</pre>
</div></div><p>A couple of API implementations is available. Please note that
if no implementation is detected on the runtime class-path then the constraints
validation won't have any effect.</p><h2
id="ValidationFeature-UsingHibernateValidatorasbeanvalidationprovider">Using
Hibernate Validator as bean validation provider</h2><p><a shape="rect"
class="external-link"
href="http://www.hibernate.org/subprojects/validator.html"
rel="nofollow">http://www.hibernate.org/subprojects/validator.html</a></p><p>Hibernate
Validator is a mature and feature-rich validation provider with the full Bean
Validation 1.1 support (as of version 5.x.x which is the reference
implementation for JSR 349 - Bean Validation 1.1 API). Add the following
dependency:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><dependency>
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.0.2.Final</version>
@@ -180,7 +180,7 @@ div.rbtoc1505311217461 li {margin-left:
</dependency>
</pre>
</div></div><h1
id="ValidationFeature-CommonBeanValidation1.1Interceptors">Common Bean
Validation 1.1 Interceptors</h1><p>JAX-RS and JAX-WS frontends can rely on the
following common interceptors to get Bean Validation 1.1 done:</p><ul
class="alternate"><li><a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/validation/BeanValidationInInterceptor.java">org.apache.cxf.validation.BeanValidationInInterceptor</a>:
validates resource method parameters against validation constraints, raises
javax.validation.ConstraintViolationException if any violations are
encountered</li></ul><ul class="alternate"><li><a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/validation/BeanValidationOutInterceptor.java">org.apache.cxf.validation.BeanValidationOutInterceptor</a>:
validates resource method response values against validation constraints,
raises <a shape="rect" c
lass="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/validation/ResponseConstraintViolationException">org.apache.cxf.validation.ResponseConstraintViolationException</a>
if any violations are encountered.</li></ul><p>Both interceptors depend on <a
shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/validation/BeanValidationProvider.java">org.apache.cxf.validation.BeanValidationProvider</a>
which abstracts away Bean Validation 1.1 API and provides useful utility
methods. This provider can be directly injected into the interceptors as a
'provider' property. Injecting the provider is optional, the interceptors will
create a default provider instance if it has not been injected.</p><p>CXF
exception handlers can check if a caught javax.validation.ValidationException
is an instance of CXF-specific ResponseConstraintViolationException in order to
find whether the failure occurr
ed during the return value validation or not.</p><p>The provider can be
initialized with javax.validation.ParameterNameProvider or <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/validation/ValidationConfiguration.java">ValidationConfiguration</a>
in order to customize the way Bean Validation 1.1 implementation does its
work.</p><p>Note that interceptors will only be effective if the current
service object is a singleton. They will make a best effort of getting hold of
a reference to the current service object, which can also be injected directly
as a 'serviceObject' property.</p><p>Custom interceptors can customize the
default processing (for example, see the section on Bean Validation 1.1 in
JAX-RS 2.0). Typical customization is to have one of the input parameters or
the response value unwrapped before it can be validated.</p><p><a shape="rect"
class="external-link" href="http://svn.apache.org/repos/asf/cxf/tr
unk/core/src/main/java/org/apache/cxf/validation/BeanValidationFeature.java">org.apache.cxf.validation.BeanValidationFeature</a>
can be used to register both in and out validation interceptors.</p><h2
id="ValidationFeature-Configuration">Configuration</h2><p>The following
snippets show how to get Bean Validation 1.1 interceptors activated for both
JAX-RS and JAX-WS services using Spring:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">// Interface implemented by both JAX-RS and JAX-WS
services:
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// Interface implemented by both JAX-RS and JAX-WS
services:
@WebService(targetNamespace = "http://bookworld.com")
@Path("/")
public interface BookWorld {
@@ -205,7 +205,7 @@ public class BookWorldImpl implements Bo
</pre>
</div></div><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><!-- JAX-RS and JAX-WS endpoints -->
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><!-- JAX-RS and JAX-WS endpoints -->
<jaxrs:server address="/bwrest">
<jaxrs:serviceBeans>
<ref bean="bookWorldValidation"/>
@@ -232,7 +232,7 @@ public class BookWorldImpl implements Bo
<bean id="commonValidationFeature"
class="org.apache.cxf.validation.BeanValidationFeature"/>
</pre>
</div></div><p>Check the next section for more examples specific to
JAX-RS.</p><h1 id="ValidationFeature-BeanValidation1.1andJAX-RS2.0">Bean
Validation 1.1 and JAX-RS 2.0</h1><h2
id="ValidationFeature-Server">Server</h2><p>JAX-RS 2.0 specification (Chapter
7) introduces an optional requirement to get Bean Validation 1.1
supported.</p><p>Using the common interceptors described in the previous
section can be sufficient for JAX-RS 2.0 resource methods having their input
parameters and response values validated.</p><p>However, if you need a response
values wrapped in JAX-RS Response validated or make sure per-request service
instances get validated then JAX-RS frontend specific interceptors and the
invoker need to be used:</p><ul
class="alternate"><li>org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor:
validates JAX-RS resource method parameters. At the moment it is nearly
identical to the common BeanValidationInInterceptor which it extends. It can
also be used as a JAX-RS
2.0 ContainerRequestFilter</li></ul><ul
class="alternate"><li>org.apache.cxf.jaxrs.validation.JAXRSBeanValidationOutInterceptor:
validates JAX-RS resource method return values, unwraps JAX-RS Response. It
can also be used as a JAX-RS 2.0 ContainerResponseFilter</li></ul><ul
class="alternate"><li>org.apache.cxf.jaxrs.validation.JAXRSBeanValidationFeature
can be used to register both in and out validation interceptors.</li></ul><ul
class="alternate"><li>org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInvoker
needs to be used for validating non-singleton service objects, see below for
more information.</li></ul><p>Note the default JAX-RS ExceptionMapper
(org.apache.cxf.jaxrs.validation.ValidationExceptionMapper) which transforms
javax.validation.ValidationException to corresponding HTTP status code has to
be registered. Users can register the custom mappers if
preferred.</p><p>org.apache.cxf.jaxrs.validation.JAXRSParameterNameProvider can
be registered directly with the common Bean
ValidationProvider to get the error messages customized.</p><p>JAX-RS 2.0
developers should prefer using JAX-RS frontend specific interceptors when
possible to make sure JAX-RS specific fixes are picked up automatically.</p><h3
id="ValidationFeature-Validationofnon-singletonserviceobjects">Validation of
non-singleton service objects</h3><p>The non-singleton service objects are
created in CXF JAXRSInvoker therefore its subclass
org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInvoker needs to be
registered if these objects need to be validated.</p><p>Register it either in a
jaxrs:invoker block when using Spring or Blueprint or with a "jaxrs.invoker"
servlet init parameter when using CXFNonSpringJaxrsServlet.</p><p> </p><h3
id="ValidationFeature-ConfiguringBeanValidation1.1usingJAXRSServerFactoryBean">Configuring
Bean Validation 1.1 using JAXRSServerFactoryBean</h3><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">JAXRSServerFactoryBean sf = new
JAXRSServerFactoryBean();
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">JAXRSServerFactoryBean sf = new
JAXRSServerFactoryBean();
sf.setResourceClasses( ... );
sf.setResourceProvider( ... );
sf.setProvider(new ValidationExceptionMapper());
@@ -241,7 +241,7 @@ sf.setOutInterceptors(Arrays.< Interc
sf.create();
</pre>
</div></div><h3
id="ValidationFeature-ConfiguringBeanValidation1.1usingSpringbeandefinitionsXML">Configuring
Bean Validation 1.1 using Spring bean definitions XML</h3><p>Following the
similar approach as for JAXRSServerFactoryBean, in case of Spring respective
bean definitions should be added under <jaxrs:outInterceptors>,
<jaxrs:inInterceptors> and <jaxrs:providers> sections,
f.e.:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;"><jaxrs:server address="/">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxrs:server address="/">
<jaxrs:inInterceptors>
<ref bean="validationInInterceptor" />
</jaxrs:inInterceptors>
@@ -271,7 +271,7 @@ sf.create();
</bean>
</pre>
</div></div><h3
id="ValidationFeature-ValidationExceptionsandHTTPstatuscodes">Validation
Exceptions and HTTP status codes</h3><p>As per JAX-RS 2.0 specification, any
input parameter validation violation is mapped to HTTP status code 400 Bad
Request and any return value validation violation (or internal validation
violation) is mapped to HTTP status code 500 Internal Server Error. This is
essentially what org.apache.cxf.jaxrs.validation.ValidationExceptionMapper
does.</p><div class="confluence-information-macro
confluence-information-macro-note"><span class="aui-icon aui-icon-small
aui-iconfont-warning confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>The details of validation
exceptions are not currently included into the response but only logged.
Application developers are encouraged to register custom exception mappers if
reporting the validation error details is required.</p></div></div><h2
id="ValidationFeature-ClientProxies">Client Prox
ies</h2><p>CXF 3.1.9 introduces an
org.apache.cxf.jaxrs.client.validation.JAXRSClientBeanValidationFeature which
can be used to validate the request parameters of a JAX-RS proxy method.</p><h1
id="ValidationFeature-CustomizingValidationProvider">Customizing Validation
Provider</h1><p><a shape="rect" class="external-link"
href="https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=core/src/main/java/org/apache/cxf/validation/BeanValidationProvider.java;h=2efc7a15f79646d93af9588244c726832221461d;hb=HEAD">org.apache.cxf.validation.BeanValidationProvider</a>
is a wrapper around javax.validation.ValidationFactory and used by CXF
validation interceptors.</p><p>It is created if it has not been injected.
However if one needs to customize javax.validation.ValidationFactory then a
custom BeanValidationProvider instance can be injected via the 'provider'
property into</p><p>the bean validation interceptors.BeanValidationProvider has
the default constructor, the one accepting javax.validat
ion.ParameterNameProvider, etc, see the source for more details.</p><p>For
example, one can customize the way parameters can be described on the JAX-RS
path by injecting <a shape="rect" class="external-link"
href="https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/validation/JAXRSParameterNameProvider.java;h=62898defcedf0f1f27505273a9ae34dc9adea528;hb=HEAD">JAXRSParameterNameProvider</a>
into BeanValidationProvider.</p><h1
id="ValidationFeature-Examples">Examples</h1><p>The following examples show
JAX-RS resource methods being validated but predefined or custom Bean
Validation 1.1 constraints can be applied to JAX-WS service methods exactly the
same way.</p><h2
id="ValidationFeature-Validatingsimpleinputparameters">Validating simple input
parameters</h2><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@POST
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@POST
@Path("/books")
public Response addBook(
@NotNull @Pattern(regexp = "\\d+") @FormParam("id") String id,
@@ -281,7 +281,7 @@ public Response addBook(
}
</pre>
</div></div><h2
id="ValidationFeature-Validatingcomplexinputparameters">Validating complex
input parameters</h2><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@POST
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@POST
@Path("/books")
public Response addBook( @Valid Book book ) {
// do some work
@@ -289,7 +289,7 @@ public Response addBook( @Valid Book boo
}
</pre>
</div></div><p>This example assumes that class Book has validation constraints
defined:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">public class Book {
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class Book {
@NotNull @Pattern(regexp = "\\d+") private String id;
@NotNull @Size(min = 1, max = 50) private String name;
@@ -297,7 +297,7 @@ public Response addBook( @Valid Book boo
}
</pre>
</div></div><h2
id="ValidationFeature-Validatingreturnvalues(non-Response)">Validating return
values (non-Response)</h2><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@GET
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@GET
@Path("/books/{bookId}")
@Override
@NotNull @Valid
@@ -306,7 +306,7 @@ public Book getBook(@PathParam("bookId")
}
</pre>
</div></div><p>This example assumes that class Book has validation constraints
defined (as in example above).</p><h2
id="ValidationFeature-Validatingreturnvalues(Response)">Validating return
values (Response)</h2><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">@GET
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@GET
@Path("/books/{bookId}")
@Valid @NotNull
public Response getBookResponse(@PathParam("bookId") String id) {
Modified: websites/production/cxf/content/docs/webservicecontext.html
==============================================================================
--- websites/production/cxf/content/docs/webservicecontext.html (original)
+++ websites/production/cxf/content/docs/webservicecontext.html Wed Sep 13
15:05:52 2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -121,7 +121,7 @@ Apache CXF -- WebserviceContext
<p> The following code fragment show how to use some parts of the
WebserviceContext.</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
public class CustomerServiceImpl implements CustomerService {
@Resource
WebServiceContext wsContext;
Modified: websites/production/cxf/content/docs/websocket.html
==============================================================================
--- websites/production/cxf/content/docs/websocket.html (original)
+++ websites/production/cxf/content/docs/websocket.html Wed Sep 13 15:05:52 2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ Apache CXF -- WebSocket
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><div class="confluence-information-macro
confluence-information-macro-note"><span class="aui-icon aui-icon-small
aui-iconfont-warning confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>This page summarizes the current
status of WebSocket support in CXF. This feature is currently only available in
trunk (CXF 3.0.0-SNAPSHOT).</p></div></div><h1
id="WebSocket-UsingtheWebSockettransport">Using the WebSocket
transport</h1><p>The intention for providing the WebSocket transport in CXF is
to turn CXF endpoint services capable of reading or writing data over the
socket that is connected to the client. For example, a JAXRS service using the
WebSocket transport can continuously push or write data (e.g., status changes,
events, etc) to the client once the client establishes a WebSocket connection
to the service.</p><p> </p><h1 id="WebSocket-CurrentStatus">Current
Status</h1><h3 id="WebSocket-Shortsummary">Short summary</h
3><ul style="list-style-type: square;"><li>The code resides in
rt/transport/http-websocket and it enables cxf services to be invoked over
websockets.</li><li>It supports both the embedded mode and the servlet
container mode. The former can be used in the standalone setup that uses an
embedded jetty server and the latter can be used in the container setup that
uses the servlet container provided by the container.</li><li>Some test cases
are located in
systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/websocket and
systests/jaxws/src/test/java/org/apache/cxf/systest/jaxws/websocket. There is
also a browser based demo
at distribution/src/main/release/samples/jax_rs/websocket.</li><li> Several
additional libraries are required to enable this feature depending on the
usage. Concretely, jetty-websocket is required for the embedded standalone mode
(i.e., the endpoint is given with the host and port part as in address="<a
shape="rect" href="ws://hostport" rel="nofollo
w">ws://host:port/path</a>"). For the servlet mode (i.e., the endpoint is
given using a relative path (i.e., address="/path"), it requires either
jetty-websocket to use jetty or atmosphere-runtime and a specific websocket
implementation such as jetty-websocket or tomcat-websocket to use that specific
container's websocket capability.</li></ul><h3
id="WebSocket-UsagePatterns">Usage Patterns</h3><p><span style="font-size:
14.0px;line-height: 1.4285715;">We have the following message exchange patterns
to use this websocket transport for cxf service
invocation.</span></p><ol><li>the client opens a websocket to some URL hosting
a cxf service (e.g. <a shape="rect" href="ws://localhost:8080/cxf/myapp/books"
rel="nofollow">ws://localhost:8080/cxf/myapp/books</a>)</li><li><p><span
style="line-height: 1.4285715;">the client can subsequently invoke an operation
provided by this service (e.g., the book order operation at
/myapp/books/order/123) by sending a request message that a simplified HTT
P request message.</span><br clear="none"><span style="line-height:
1.4285715;"><br clear="none"></span></p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>Request Syntax</b></div><div
class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">Request = Request-Line CRLF
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">Request = Request-Line CRLF
*(( header ) CRLF)
CRLF
[ body ]
@@ -127,7 +127,7 @@ Request-Line = Method SP Request-URI
</pre>
</div></div><p> </p><p>Method uses the HTTP methods.</p><p>header may
include any headers that are required by CXF to determine the operation and
expected by the operation itself (e.g., Content-Type).</p><br
clear="none"><span style="line-height: 1.4285715;"><br
clear="none"></span></li><li><p><span style="line-height: 1.4285715;">the
response message returned by the the service is sent back to the client
as</span><br clear="none"><span style="line-height: 1.4285715;"><br
clear="none"></span></p><div class="code panel pdl" style="border-width:
1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width:
1px;"><b>Request Syntax</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">Response = [ Status-Line CRLF ]
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">Response = [ Status-Line CRLF ]
*(( header ) CRLF)
CRLF
[ body ]
Modified: websites/production/cxf/content/docs/ws-addressing.html
==============================================================================
--- websites/production/cxf/content/docs/ws-addressing.html (original)
+++ websites/production/cxf/content/docs/ws-addressing.html Wed Sep 13 15:05:52
2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -123,7 +123,7 @@ Apache CXF -- WS-Addressing
<p>To enable WS-Addressing you may enable the WSAddressingFeature on your
service. If you wish to use XML to configure this, you may use the following
syntax:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
<jaxws:endpoint id="{your.service.namespace}YourPortName">
<jaxws:features>
<wsa:addressing xmlns:wsa="http://cxf.apache.org/ws/addressing"/>
@@ -133,7 +133,7 @@ Apache CXF -- WS-Addressing
</div></div>
<p>You can also use the same exact syntax with a <jaxws:client></p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
<jaxws: client id="{your.service.namespace}YourPortName">
<jaxws:features>
<wsa:addressing xmlns:wsa="http://cxf.apache.org/ws/addressing"/>
@@ -143,7 +143,7 @@ Apache CXF -- WS-Addressing
</div></div>
<p> From an API point of view this looks very similar:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
import org.apache.cxf.jaxws.EndpointImpl;
import org.apache.cxf.ws.addressing.WSAddressingFeature;
@@ -155,7 +155,7 @@ ep.publish("http://some/address");
</div></div>
<p>You can also use it with the ClientProxyFactoryBeans and ServerFactoryBeans
(and their JAX-WS versions, namely JaxWsProxyFactoryBean and
JaxWsServerFactoryBean):</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
import org.apache.cxf.frontend.simple.ClientProxyFactoryBean;
import org.apache.cxf.ws.addressing.WSAddressingFeature;
@@ -177,7 +177,7 @@ MyService client = (MyService) factory.c
<p>The HTTP Conduit's client configuration has an option for a
DecoupledEndpoint address. If the conduit has this configured, all requests
sent via that conduit that have WS-Addressing enabled will have their responses
sent to that endpoint:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
<http:conduit
name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
<http:client
DecoupledEndpoint="http://localhost:9090/decoupled_endpoint"/>
</http:conduit>
@@ -187,7 +187,7 @@ MyService client = (MyService) factory.c
<h3 id="WS-Addressing-RequestProperty">Request Property</h3>
<p>The address can be set via a Request Context property. </p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
((BindingProvider)proxy).getRequestContext()
.put("org.apache.cxf.ws.addressing.replyto",
"http://localhost:9090/decoupled_endpoint");
</pre>
@@ -196,7 +196,7 @@ MyService client = (MyService) factory.c
<h3 id="WS-Addressing-AddressingProperties">AddressingProperties</h3>
<p>The CXF org.apache.cxf.ws.addressing.impl.AddressingPropertiesImpl object
can be used to control many aspects of WS-Addressing including the Reply-To:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
AddressingProperties maps = new AddressingPropertiesImpl();
EndpointReferenceType ref = new EndpointReferenceType();
AttributedURIType add = new AttributedURIType();
Modified: websites/production/cxf/content/docs/ws-discovery.html
==============================================================================
--- websites/production/cxf/content/docs/ws-discovery.html (original)
+++ websites/production/cxf/content/docs/ws-discovery.html Wed Sep 13 15:05:52
2017
@@ -133,7 +133,7 @@ Apache CXF -- WS-Discovery
<p>CXF also provides an API to probe the network or WS-Discovery proxy. The
org.apache.cxf.ws.discovery.WSDiscoveryClient class provides several methods
for probing the network. </p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
//Use WS-Discovery to find references to services that implement the Greeter
portType
WSDiscoveryClient client = new WSDiscoveryClient();
// or: new WSDiscoveryClient("soap.udp://proxyhost:3702");
Modified: websites/production/cxf/content/docs/ws-metadataexchange.html
==============================================================================
--- websites/production/cxf/content/docs/ws-metadataexchange.html (original)
+++ websites/production/cxf/content/docs/ws-metadataexchange.html Wed Sep 13
15:05:52 2017
@@ -120,7 +120,7 @@ Apache CXF -- WS-MetadataExchange
dependency will need to be included in your project:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-mex</artifactId>
Modified: websites/production/cxf/content/docs/ws-policy-framework-overview.html
==============================================================================
--- websites/production/cxf/content/docs/ws-policy-framework-overview.html
(original)
+++ websites/production/cxf/content/docs/ws-policy-framework-overview.html Wed
Sep 13 15:05:52 2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -141,7 +141,7 @@ Apache CXF -- WS-Policy Framework Overvi
<p>AssertionBuilder implementations are loaded dynamically and are
automatically registered with the AssertionBuilderRegistry, which is available
as a Bus extension. Currently, CXF supports AssertionBuilder and Assertion
implementations for the following assertion types:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
{http://schemas.xmlsoap.org/ws/2005/02/rm/policy}RMAssertion
{http://www.w3.org/2007/01/addressing/metadata}Addressing
{http://www.w3.org/2007/01/addressing/metadata}AnonymousResponses
@@ -158,7 +158,7 @@ Apache CXF -- WS-Policy Framework Overvi
<p>This API is used to automatically engage interceptors required to support
domain specific assertions at runtime, thus simplifying interceptor
configuration a lot.</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
public interface PolicyInterceptorProvider extends InterceptorProvider {
// return the schema types of the asssertions that can be supported
Collection<QName> getAssertionTypes()
@@ -167,7 +167,7 @@ public interface PolicyInterceptorProvid
</div></div>
<p>Currently, CXF supports PolicyInterceptorProvider implementations for the
following assertion types:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
{http://schemas.xmlsoap.org/ws/2005/02/rm/policy}RMAssertion
{http://www.w3.org/2007/01/addressing/metadata}Addressing
{http://www.w3.org/2007/01/addressing/metadata}AnonymousResponses
@@ -186,7 +186,7 @@ public interface PolicyInterceptorProvid
<p>Like most other CXF features, the policy framework is itself largely
interceptor based. Thus, most interaction with the framework is indirect
through the Message object: Policy interceptors make AssertionInfo objects
(stateful representations of assertions) available to subsequently executing,
policy-aware interceptors by inserting them into the Message object. Extracting
the AssertionInfo objects from the Message allows interceptors to perform steps
1. and 2. above: </p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
import org.apache.neethi.Assertion;
public class AssertionInfo {
@@ -206,7 +206,7 @@ And Destinations cannot normally exhibit
<p>Their interaction with the policy framework therefore typically involves
the PolicyEngine through which they obtain the effective policy for the
underlying endpoint (for step 1.):</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
public interface PolicyEngine {
...
EndpointPolicy getClientEndpointPolicy(EndpointInfo ei,
@@ -225,7 +225,7 @@ public interface EndpointPolicy {
<p>To perform step 2. they implement the Assertor interface (namely its
assertMessage method):</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
public class Assertor {
...
public boolean canAssert(QName name);
Modified: websites/production/cxf/content/docs/ws-reliablemessaging.html
==============================================================================
--- websites/production/cxf/content/docs/ws-reliablemessaging.html (original)
+++ websites/production/cxf/content/docs/ws-reliablemessaging.html Wed Sep 13
15:05:52 2017
@@ -32,8 +32,8 @@
<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/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -149,7 +149,7 @@ Apache CXF -- WS-ReliableMessaging
<p>For example, if you have the JMX server enabled in your client
configuration you could use this code to track the last acknowledgement number
received:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
private static class AcknowledgementListener implements
NotificationListener {
private volatile long lastAcknowledgement;
Modified: websites/production/cxf/content/docs/ws-secureconversation.html
==============================================================================
--- websites/production/cxf/content/docs/ws-secureconversation.html (original)
+++ websites/production/cxf/content/docs/ws-secureconversation.html Wed Sep 13
15:05:52 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/shBrushJava.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.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>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -135,7 +135,7 @@ Apache CXF -- WS-SecureConversation
<p>Configuring the WS-SecurityPolicy properties for WS-SecureConversation
works exactly like the configuration for straight WS-SecurityPolicy. The only
difference is that there needs to be a way to specify which properties are
intended for the bootstrap policy in the SecureConversationToken and which are
intended for the actual service policy. To accomplish this, properties
intended for the SecureConversationToken bootstrap policy are appended with
".sct". For example:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
<jaxws:client
name="{http://InteropBaseAddress/interop}XDC-SEES_IPingService"
createdFromAPI="true">
<jaxws:properties>
@@ -155,7 +155,7 @@ Apache CXF -- WS-SecureConversation
<p>Via the Java API, use code similar to the following:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
org.apache.cxf.endpoint.Client client;
client.getRequestContext().put("ws-security.username.sct", username);
client.getRequestContext().put("ws-security.password.sct", password);
@@ -164,7 +164,7 @@ client.getRequestContext().put("ws-secur
<p>Via the Java API, use code similar to the following:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence"
style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
org.apache.cxf.endpoint.Client client;
client.getRequestContext().put("ws-security.username.sct", username);
client.getRequestContext().put("ws-security.password.sct", password);