I have some custom http headers whcih would like to include in span tags. the custom headers depends on applications. possible to do that?

Giving name to spans based on the HTTP Method does not look intuitive on the tracers UI(Jaeger, Lightstep, Zipkin etc). For example there can be several PUT
requests and the span will look in the UI with name "PUT" in the tracer. A viewer cannot figure out that PUT request is related with which URL(or which service) until he click on the span and checks the tags.
Here is the view from Lightstep (Note : regdiscovery-tracer is the name of the tracer)

I think it will good to use request URL instead of HTTP Method so that viewer at the first view on the tracer UI can figure out the particular span is meant for which http request.

Similar to #45 and #42, I'd like different operation names than are provided by this library by default.

Instead of changing the default on everybody already using the library or using a potentially high cardinality field like requestURL, provide an API for customizing the operation naming strategy. The java-grpc OpenTracing contrib provides a similar option: https://github.com/opentracing-contrib/java-grpc/blob/master/src/main/java/io/opentracing/contrib/grpc/OperationNameConstructor.java

I'm happy to contribute a PR.

There are some implementations (I've observed) of OpenTracing that do not accept null arguments to SpanBuilder.asChildOf(). If tracer.extract() returns null (ie. no span context was passed to the servlet) and it is used to create a child span, .asChildOf() will cause a NullPointerException.

The equivalent operation would be to avoid calling .asChildOf() if extractedContext is null, which should work for any implementation.

https://github.com/opentracing-contrib/java-web-servlet-filter/blob/master/opentracing-web-servlet-filter/src/main/java/io/opentracing/contrib/web/servlet/filter/ServletFilterSpanDecorator.java#L109-L112

It might look not very important however as far as I can
see most of the other opentracing-X project has a license as a header.
I faced with this during IP certification process when I
want to include opentracing-web-servlet-filter to Eclipse Che project.
I hope that the license in the root folder is enough for IP team. But who knows...
I can submit PR if needed.

Thoughts?

https://jakarta.ee/specifications/servlet/5.0/
To be able to use with Jetty 11 & Tomcat 10.
Related issue eclipse-che/che#20247

I have a spring boot service with @ControllerAdvice and @ExceptionHandler. These mechanism swallow the exception and it never reaches the TracerFilter and span is not tagged as error.

Can we also check the status code and decide if the Span should be tagged as error in OnResponse of the default decorator.

Please add to README which Servlet API minimal version is supported?
I expect it doesn't work for Servlet API below 3.0.

This happened:

java.util.NoSuchElementException
1 at java.util.ArrayList$Itr.next (ArrayList.java:854)
2 at io.opentracing.contrib.web.servlet.filter.HttpServletRequestExtractAdapter$MultivaluedMapFlatIterator.next (HttpServletRequestExtractAdapter.java:84)
3 at io.opentracing.contrib.web.servlet.filter.HttpServletRequestExtractAdapter$MultivaluedMapFlatIterator.next (HttpServletRequestExtractAdapter.java:58)

The request came with header without values:

Accept: application/json
Broken-Header: 
Content-Type: application/json

There's a test for this case with comment that "this should not really happen" but it happens :)

I was running 0.0.3, but 0.0.7 seems to have the same logic.

I noticed that several interfaces have anonymous implementation in it.

• STANDARD_TAGS in ServletFilterSpanDecorator
• STANDARD_LOGS in HandlerInterceptorSpanDecorator
• HANDLER_METHOD_OPERATION_NAME in HandlerInterceptorSpanDecorator

Is there a reason?

I wanted to add queryString to Tags.HTTP_URL but since I can't extend STANDARD_TAGS, I have to create my own class and copy paste all methods and change what I need. If I could extend the class, I could have just override onRequest.

Hi! 👋 I have some questions, since the repo has not been updated for a few years.

1. What is the current status of this project?
2. Is it still being maintained?
3. Is there an alternative that could be used?

Currently only a pom is provided.

It looks like this is the case for all versions: https://search.maven.org/search?q=a:opentracing-web-servlet-filter-parent

ClientAbortException happen in Tomcat when the client disconnected before the response from the server.
Can obviously happen at any time since it's upto the client when to disconnect or not.
Tomcat and Spring are both ignoring this exception and the Tomcat access log valve shows response as 200 still (what would have been returned, had the client not disconnected).

Tomcat version: 9.0.63
Ignoring of client aborts was added in Tomcat with 9.0.13 - https://bz.apache.org/bugzilla/show_bug.cgi?id=62797

But TracingFilter catches all Throwable-s:
https://github.com/opentracing-contrib/java-web-servlet-filter/blob/master/opentracing-web-servlet-filter/src/main/java/io/opentracing/contrib/web/servlet/filter/TracingFilter.java#L198

And then ServletFilterSpanDecorator goes ahead and reports the span with status 500:
https://github.com/opentracing-contrib/java-web-servlet-filter/blob/master/opentracing-web-servlet-filter/src/main/java/io/opentracing/contrib/web/servlet/filter/ServletFilterSpanDecorator.java#L113

Exception from the request that is still reported as successful by Tomcat:

	at io.opentracing.contrib.web.servlet.filter.TracingFilter.doFilter(TracingFilter.java:189)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
	at ch.qos.logback.access.tomcat.LogbackValve.invoke(LogbackValve.java:256)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
	at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1743)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
	at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
	at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:353)
	at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783)
	at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:688)
	at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:388)
	at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:366)
	at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)

This should be helpful for use cases like: checking application health on openshift, disable favicon, swagger docs..

异常信息如下：
java.lang.NullPointerException at brave.opentracing.BraveSpanBuilder.addReference(BraveSpanBuilder.java:72) at brave.opentracing.BraveSpanBuilder.asChildOf(BraveSpanBuilder.java:60) at brave.opentracing.BraveSpanBuilder.asChildOf(BraveSpanBuilder.java:41) at io.opentracing.contrib.web.servlet.filter.TracingFilter.doFilter(TracingFilter.java:154) at com.efounder.opentracing.OpentracingFilter.doFilter(OpentracingFilter.java:28)

filter 代码如下：

`public class OpentracingFilter implements Filter {

private TracingFilter filter = null;

@Override
public void init(FilterConfig filterConfig) throws ServletException {
	Tracer tracer = OpentracingManager.me().getTracer();
	filter = new TracingFilter(tracer);
}

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
		throws IOException, ServletException {
	filter.doFilter(request, response, chain);
}

@Override
public void destroy() {
	filter.destroy();
}

}`

请指教

https://github.com/opentracing-contrib/java-web-servlet-filter/blob/master/opentracing-web-servlet-filter/src/main/java/io/opentracing/contrib/web/servlet/filter/TracingFilter.java#L151

if extractedContext is null then .asChildOf(extractedContext) here can produce NPE and it does for Lightstep tracer

As is documented in the comments of MimeHeaders, each call of nextElement() has a complexity of O(n) with a comparison done with all previous elements to ensure the uniqueness.

Jetty has better performance since it uses HashSet to get a set of header keys.

I wonder if we could treat org.apache.catalina.connector.Request as a special case. A simple index-based iteration does improve the performance.

https://github.com/opentracing-contrib/java-web-servlet-filter/blob/master/opentracing-web-servlet-filter/src/main/java/io/opentracing/contrib/web/servlet/filter/TracingFilter.java#L197

Reqirement

for example, I have a service. Service have two http interface, and both are POST method:

• http://localhost/decrypt
• http://localhost/encrypt

I want to set different sampling for interfaces above:

{
  "service_strategies": [
    {
      "service": "myservice",
      "type": "probabilistic",
      "param": 0.8,
      "operation_strategies": [
        {
          "operation": "encrypt",
          "type": "probabilistic",
          "param": 0.4
        },
        {
          "operation": "decrypt",
          "type": "probabilistic",
          "param": 0.6
        }
      ]
    }
  ]
}

Main Question

Because all operation name are http method, how can I set different sampling configuration for them?

Thinking

1, I want to change operation name by ServletFilterSpanDecorator, but it performs after sampler action.

2, According to #42 and #45, it is not recommended to change operation name. Two reasons as following:

• request URI may have multiple pattern. /user/{id}
• high cardinality

(1) request URI may have multiple pattern.
If resolves multiple pattern problem, jaeger-client maybe need to implement pattern resolver.

(2) high cardinality. It is appreciated that talk more details about high cardinality, such as high cardinality affects what(storage? query? or others?) @pavolloffay

Here's the story: HttpServletRequestExtractAdapter extracts all the header values into a map. Just wondering, what would be the best way for it to skip some specific headers. For instance, I don't want to extract Authorization header (otherwise it's propagated to outgoing requests by some implementations of Tracer).

Does it make sense to add some control to HttpServletRequestExtractAdapter? Like, passing a filter function to the constructor.

Currently the span names are set to the method of the request, e.g. POST.

It would be helpful if this were something like: 'HTTP POST api/v1/foo/'
or just included the endpoint.

Alternatively, we could configure the tracer with a function that returns a span name from a request.

See opentracing/opentracing-java#295

Similar to the linked issue from the main opentracing-java repository, the idea is to measure how much overhead the OT instrumentation is adding when compared to the same application without the filter.

This can be accomplished by using Undertow and JMH.

There might be use cases when an async request has been already finished/completed before async listener is added. Then server span would not be closed.