|  | [//]: # " Copyright (c) 2015, 2018 Oracle and/or its affiliates. All rights reserved. " | 
|  | [//]: # " " | 
|  | [//]: # " This program and the accompanying materials are made available under the " | 
|  | [//]: # " terms of the Eclipse Distribution License v. 1.0, which is available at " | 
|  | [//]: # " http://www.eclipse.org/org/documents/edl-v10.php. " | 
|  | [//]: # " " | 
|  | [//]: # " SPDX-License-Identifier: BSD-3-Clause " | 
|  |  | 
|  | Jersey OpenTracing Example | 
|  | ========================== | 
|  |  | 
|  | This example demonstrates Jersey OpenTracing integration. The JAX-RS resource contains several resource method showing various | 
|  | possibilities. | 
|  |  | 
|  | This particular example is configured with Jaeger as the GlobalTracer, but can be easily adjusted to use any other tracer | 
|  | implementation. | 
|  |  | 
|  | Running the Example | 
|  | ------------------- | 
|  | Example can be launched as is, but does not perform any interesting action out of the box. | 
|  | To be able to visualise the traces, it is recommended to start Jaeger (and th UI) locally, e.g. in Docker: | 
|  |  | 
|  | >     docker run -d -p 5775:5775/udp -p 16686:16686 jaegertracing/all-in-one:travis-1278 | 
|  |  | 
|  | Check the UI on [localhost:16686](http://localhost:16686), there should be no traces visible. | 
|  |  | 
|  | Run the example as follows: | 
|  |  | 
|  | >     mvn clean compile exec:java | 
|  |  | 
|  | This deploys the example using [Grizzly](http://grizzly.java.net/) container. | 
|  |  | 
|  | Try to access resources using the URIs listed bellow and look into Jager UI what traces are produced. | 
|  | The first example should be visible in the Jaeger UI right after the example application is started. Others can be created by | 
|  | doing rest calls to the exposed resource. | 
|  |  | 
|  | 1. On start, the example application sends one request demonstrating more complex tracing | 
|  | - jersey client (w/ registered OpenTracingFeature) creates the "jersey-client-GET" span | 
|  | - the span is propagated to server (via http headers), jersey server (w/ registered OpenTracinfFeature) automatically creates a | 
|  | child span of the client span | 
|  | - in the resource method, child span of the server span is manually created and propagated into managed client calls | 
|  | - the managed clients are also tracing-enabled, so each one creates its own child span, that is propagated to the server, and | 
|  | so on | 
|  |  | 
|  | 2. No explicit (user-defined) spans. | 
|  | - one automatically created "root" span, that measures the processing on the Jersey side and one "resource-level" span to be | 
|  | used for logging events on the application level | 
|  | - the "root" contains several tags with request and response metadata, such as request headers, status code, etc | 
|  | - also, several technical Jersey-level events have been logged | 
|  | - to see this simple case, call | 
|  | >     curl localhost:8080/opentracing/resource/defaultTrace | 
|  |  | 
|  | 3. Explicit logging into resource-level span | 
|  | - same as above, but the "resource-level" span was resolved within the application logic, an event was logged and a tag was added | 
|  | >     curl localhost:8080/opentracing/resource/appLevelLogging | 
|  |  | 
|  | - similar call with POST: | 
|  | >     curl -X POST -d "Jersey Rocks" localhost:8080/opentracing/resource/appLevelPost | 
|  |  | 
|  |  | 
|  | 4. Explicit child span creation | 
|  | - same as above, but instead of "resource-level" span, a child span was created and used for logging and adding tags | 
|  | - note, that such a span needs to be finished manually, otherwise it won't propagate (the tracing info will be lost) | 
|  | >     curl localhost:8080/opentracing/resource/childSpan | 
|  |  | 
|  |  | 
|  | 4. Client calls from the resource | 
|  | - more complex case, the resource method invokes two client calls using managed client | 
|  | - one request via managed client is triggered within the "provided", resource-level span | 
|  | - child span is created and another request via manged client is triggered within the child span | 
|  | - the span context needs to be propagated manually using the OpenTracingFeature.SPAN_CONTEXT_PROPERTY | 
|  | - in both cases, the span context is propagated using http headers to the server and back to the client | 
|  | - the child span (created in the resource) needs to be explicitly finished in the resource (or elsewhere, but needs to be finished) | 
|  | >     curl localhost:8080/opentracing/resource/traceWithManagedClient | 
|  |  | 
|  | 5. Asynchronous processing | 
|  | - either basic case, but using asynchronous request processing | 
|  | - there should be no practical difference visible in the tracing info | 
|  | >     curl localhost:8080/opentracing/resource/async | 
|  |  | 
|  | 6. Failing resource | 
|  | - demonstrates exception thrown in the resource method | 
|  | - Jaeger shows failed spans with the exclamation mark symbol and the exception is logged in the request span | 
|  | >     curl localhost:8080/opentracing/resource/error |