You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by dk...@apache.org on 2017/09/13 15:05:57 UTC
svn commit: r1018111 [28/33] - in /websites/production/cxf/content: ./
cache/ docs/
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);