Will the Java SDK eventually support Open Tracing like Go SDK? Thank you!
Yes, absolutely. Our goal is to fix interceptors to the point that Open Tracing (or any other similar) framework would be added without modification to the core SDK.
Hello @maxim , was it implemented?
@spikhalskiy has a PR that adds header support to the activity interceptor. After the PR is landed implementing the Open Tracing support will be next.
Support for OpenTracing and OpenTelemetry is now added to Java SDK. Please use a temporal-opentracing module: sdk-java/temporal-opentracing at master ¡ temporalio/sdk-java ¡ GitHub
Hi,
I have made changes in my sample project to initialize client and the worker with OpenTracingClientInterceptor. But I am unable to understand about the configuration required, so that the traces can be checked using Jaeger UI. Please help with the clarification. Thanks!
Working on a sample for this atm.
Take a look at OpenTracing sample PR here. It uses CNCF Jaeger. It still needs to go through the review process but hope it gives you an idea on how to set it up (see README.md) for instructions.
1 Like
Added support for both OpenTelemetry and OpenTracing in the sample.
2 Likes
Has anyone tried the opentelemetry java agent with the temporal java worker?
Havenât personally, but Java SDK temporal-opentracing module provides support for OpenTelemetry via OpenTracingShim so it could work.
I tried the opentelemetry/ opentracing support using the java sdk. Its great. But we do have activities calling remote services and we wanted to include tracing with those remote services.
Currently the activity do not get access to these trace information. I saw the samples using MDC and context propagator, just wondering if that is the only avenue?
Thanks again!!
I am having difficulty getting the trace context from the Payload in my custom ContextPropagator and convert it to an Opentelemetry tracer. If anyone has a pointer to this will be greatly appreciated.
I think you could create and register a custom OpenTracingClientInterceptor impl that would expose ContextAccessor and can be used in your client and activity code, rather than trying to pass things as inputs to workflow/activities.
Thanks, im looking at the tracing codes. Just curious how would i be able to expose the âContextAccessorâ from an interceptor that one can access from an Activity implementation?
Another question, is the activity inbound call interceptor executing in the same call thread as the actual activity method implementation?
Im asking this because maybe i can use a ThreadLocal.
Sorry if its a dumb question
You could pass it to your activity constructor when you register activity with worker, or if you are using a framework like SpringBoot annotate your activity with @Component and autowire it in your activity. Another option I think if your have your client and activity code running on the same service, make your custom interceptor static and use directly in your activity code.
is the activity inbound call interceptor executing in the same call thread as the actual activity method implementation
I believe that is the case.
Thanks @tihomir I will try to use the interceptors. I was able to use the context propagators, i donât think it is that user friendly. If there is an example that I can copy from, that will be great.
One other note, if this is something that is part of the sdk, that will be awesome 
Appreciate all the help and great product!
if this is something that is part of the sdk,
Yes, interceptors are part of the Java SDK (and are preferred over context propagators as far as use goes)
Take a look at the interceptor sample here. It does not currently include client interceptor but will add.
I saw those samples already. Adding a client interceptor which allows an activity to access some context will greatly help ease understanding. I hope Iâm not asking too muchđ.
Is it safe to use ThreadLocal inside client interceptors?