-
Notifications
You must be signed in to change notification settings - Fork 232
Deprecate instrumentations in favor of opentracing-contrib #182
Comments
I'm assigning it to myself. Later on, do we want to deprecate jaeger wrappers too? |
If by deprecate, you mean adding I think we should remove jaeger wrappers with the first major release. |
I'm more in favor of deprecating and let users upgrade to the contrib versions. There are some potential problems:
|
Re |
But who should provide this decorator? Can we expect that they will correctly implement it? Or should be provided as |
the decorator that actually contains the |
I have to do some work on dropwizard contrib lib: The configuration will accept: tracing:
serviceName: // string
serverAddress: // string could be `http://localhost:9411/api/v1/spans` or `localhost:5984`
enabled: // to quickly disable tracing by using NoopTracer Then in the Application class users will provide tracer instance. Is this acceptable for Uber users? Other problem is that jaeger metrics won't work https://github.com/uber/jaeger-client-java/tree/master/jaeger-dropwizard#metrics, Could be https://github.com/uber/jaeger-client-java/blob/master/jaeger-dropwizard/src/main/java/com/uber/jaeger/dropwizard/StatsFactory.java and other referenced classes also provided by internal infra libs? |
Why do we need to change configuration from its current form? StatsFactory delegates to |
@yurishkuro we don't have to change jaeger configuration. I'm talking about dropwizzard configuration which could be used with any OT tracer. |
Oh... That sounds like an anti pattern. There's never going to be a generic configuration that will satisfy ALL tracers, so why even bother? Why can't each implementation have its own config? Is this somehow forced by dropwizard? |
It's not forced by dropwizard. It's just an idea how to simplify integration for most tracer. In the Application users would still have to instantiate tracer manually and pass it to integration code which would initialize jax-rs instrumentation |
@yurishkuro For 1.0 milestone, would you be ok with the framework instrumentations being moved into a separate repo, remaining under the |
Current plan, as discussed on the last bi-weekly call, is to retain the |
@yurishkuro we would like to move instrumentations and context to a separate repository. Could you please create one? Possibly under uber org if not then here in jaegertracing. This new repo will depend on com.uber jaeger client. (if it has to depend on the client) |
I don't want to move it back to uber org because of approvals, CLAs, etc. How about |
sounds good to me unfortunately we cannot fork the repo in the same org, so I will create a repo and push sources there (with full history). |
Done, instrumentations are now in legacy-client-java repo. |
Not really the same, so I rebooked it in the legacy repo. |
Many of the frameworks we instrumented in jaeger-client-java are also instrumented in opentracing-contrib. We should deprecate Jaeger-specific instrumentation.
Criteria:
The text was updated successfully, but these errors were encountered: