Rewritable Tracer not relatable to Integrations

I don’t know if “Rewritable Tracer” the feature is supported formally or not in v1.6.0, but I added the -Dsa.rewrite=xxx jvm option to my demo application and request a servlet, NullPointerException was thrown just like below

java.lang.NullPointerException
	at java.util.Objects.requireNonNull(Objects.java:203)
	at io.opentracing.contrib.specialagent.RewritableTracer.getRulesForCurrentPlugin(RewritableTracer.java:42)
	at io.opentracing.contrib.specialagent.RewritableTracer.buildSpan(RewritableTracer.java:98)
	at io.opentracing.util.GlobalTracer.buildSpan(GlobalTracer.java:194)
	at io.opentracing.contrib.specialagent.rule.servlet.ext.TracingFilterUtil.buildSpan(TracingFilterUtil.java:36)
	at io.opentracing.contrib.web.servlet.filter.TracingFilter.doFilter(TracingFilter.java:183)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)

I checked the code, I guest, AgentRule.getCurrentPluginName() return null in the invocation context (RewritableTracer.java:42). Some plugin intercept the traffic and build spans, just like redis. But most of rule interceptions are just for integrating a 3rd-party instrument, not handling traffic tracing. in that cases, buildSpan is invoked in another thread by the 3rd-party libraries, not by rule interceptions, current plugin name could not be found by AgentRule.getCurrentPluginName().

[safris]

Hi @zeitlinger, thank you for the assessment of the options. I think the best option for us here is (3). This choice retains the work that’s been done, and leaves a possibility for further improvements based on realizations we may not have yet. So, in short, I’m going to keep the implementation of Rewritable Tracer as is. Furthermore, I have written up a draft proposal for the port of this implementation to the OTel Auto Instr engine.

[safris]

Closing this, as there is nothing actionable remaining with this issue.