Migrate GWT to Instrumenter API #3146
Conversation
anuraaga
requested review from
iNikem,
jkwatson,
laurit,
mateuszrzeszutek,
pavolloffay,
trask and
tylerbenson
as code owners
| import io.opentelemetry.instrumentation.api.instrumenter.rpc.RpcSpanNameExtractor; | ||
| import java.lang.reflect.Method; | ||
|
|
||
| public final class GwtSingletons { |
There was a problem hiding this comment.
I think I've used every pattern possible for the name of this sort of class. I wonder if we should just converge on *Singletons so it can fit instrumenters, but also any other singletons that come our way.
There was a problem hiding this comment.
It looks like the RPC semantic conventions specifically target CLIENT/SERVER spans
though I can definitely see a case for RPC conventions applied to RPC systems designed on top of servlets
or maybe that's what a "handler span" is? 😂
| import io.opentelemetry.instrumentation.api.instrumenter.rpc.RpcSpanNameExtractor; | ||
| import java.lang.reflect.Method; | ||
|
|
||
| public final class GwtSingletons { |
|
I guess there's a difference between REST and RPC - I think we're only supposed to have one span here since this seems to be similar to gRPC. So I guess we should be updating any HTTP span with the RPC span name and attributes. A mode the instrumenter API doesn't yet support, and it ties into the general nested span stuff as usual :) |
| scope.close(); | ||
|
|
||
| tracer().endSpan(context, throwable); | ||
| INSTRUMENTER.end(context, method, null, throwable); |
There was a problem hiding this comment.
Do we want to use an instrumenter() static method here?
…nstrumentation into gwt-method-only
…nstrumentation into gwt-method-only
* Migrate GWT to Instrumenter API * TODO * instrumenter()
This started as me wanting to remove a usage of
SpanNames, but realized this can just be an RPC instrumentation.