anchor.diff:  }
   ----
   
  -==== io.opentracing.Tracer access
  -
  -This proposal also specifies that the underlying opentracing.io Tracer object
  +==== Access to the configured tracer
  +
  +This proposal also specifies that the underlying OpenTracing Tracer object
   configured instance is available for developer use. The MicroProfile
   implementation will make the configured Tracer available with CDI injection.
   
  
positive.code: There are existing distributed tracing systems that provide a server for distributed trace record storage and viewing, and application libraries for instrumenting microservices.
  The problem is that the different distributed tracing systems use implementation specific mechanisms for propagating correlation IDs and for formatting trace records, so once a microservice chooses a distributed tracing implementation library to use for its instrumentation, all other microservices in the environment are locked into the same choice.
  
  The http://opentracing.io/[opentracing.io project's] purpose is to provide a standard API for instrumenting microservices for distributed tracing.
  If every microservice is instrumented for distributed tracing using the opentracing.io API, then (as long as an implementation library exists for the microservice's language), the microservice can be configured at deploy time to use a common system implementation to perform the log record formatting and cross service correlation id propagation.
  The common implementation ensures that correlation ids are propagated in a way that is understandable to all services, and log records are formatted in a way that is understandable to the server for distributed trace record storage.
  
  In order to make MicroProfile distributed tracing friendly, it will be useful to allow distributed tracing to be enabled on any MicroProfile application, without having to explicitly add distributed tracing code to the application.
  
  In order to make MicroProfile as flexible as possible for adding distributed trace log records, MicroProfile should expose whatever objects are necessary for an application to use the opentracing.io API.
  
  
  == Architecture
  
  This specification defines an easy way to allow an application running in a
  MicroProfile container to take advantage of distributed tracing by using an
  opentracing.io Tracer implementation.
  
  There are two operation modes
  
  
negative.code: 
  The MicroProfile implementation will allow JAX-RS applications to participate in distributed tracing, without requiring developers to add any distributed tracing code into their applications, and without requiring developers to know anything about the distributed tracing environment that their JAX-RS application will be deployed into.
  
  1. The MicroProfile implementation must provide a mechanism to configure an `io.opentracing.Tracer` implementation for use by each JAX-RS application.
  2. The MicroProfile implementation must provide a mechanism to automatically extract SpanContext information from any incoming JAX-RS request.
  3. The MicroProfile implementation must provide a mechanism to automatically start a Span for any incoming JAX-RS request, and finish the Span when the request completes.
  4. The MicroProfile implementation must provide a mechanism to automatically inject SpanContext information into any outgoing JAX-RS request.
  5. The MicroProfile implementation must provide a mechanism to automatically start a Span for any outgoing JAX-RS request, and finish the Span when the request completes.
  
  Correct parent child relationships between incoming requests and outgoing requests are handled automatically, as long as the outgoing requests occur on the same thread as the incoming request.
  If outgoing requests are performed on a different thread than the incoming request, it is the developers responsibility to propagate the Tracer context between threads.
  
  ==== Tracer configuration
  An implementation of an `io.opentracing.Tracer` must be made available to each application. Each application will have its own Tracer instance.
  The Tracer must be configurable outside of the application to match the distributed tracing environment where the application is deployed. For example, it should be possible to take the exact same application and deploy it to an environment where Zipkin is in use, and to deploy the application without modification to a different environment where Jaeger is in use, and the application should report Spans correctly in either environment.
  
  ==== Span creation for inbound requests
  When a request arrives at a JAX-RS endpoint, configured Tracer instance is used to extract a SpanContext from the
  inbound request. The extracted context is used as a child of reference for a new Span created for this endpoint.
  
  [[server-span-name]]
  ===== Server Span name
  