Open t1 opened 1 year ago
I opened the issue here, because it looks like an integration issue. It works fine with quarkus.
Interesting, the smallrye.graphql.tracing.enabled
property was removed, so if it still has any effect, then I forgot to remove it somewhere. It should just be turned on/off automatically.
It looks like WildFly doesn't support injecting a tracer directly via CDI, which I believe it should, and smallrye-graphql tries to obtain it that way. I'll need to figure out how else we can obtain it.
When I don't enable it, then tracing works for REST, but not for GraphQL (services; we have a separate issue for GraphQL clients).
Oh, before you are searching at the wrong place, I just saw that I may have confused the versions. I had a mismatch for a while by using 2.0.0.Final with WF28. The exception I reported may be from that setting after an incomplete re-provisioning; I can't reproduce it any more.
But it still doesn't work: GraphQL requests are not being reported as spans. And if I log the trace-id (via Span.current().getSpanContext().getTraceId()
), it shows 00000000000000000000000000000000
. I could share my reproducer, if it helps.
Stupid me. I can reproduce it. I just still had a dummy producer for Tracers. Sorry for the confusion (too many topics in parallel, you know it).
Should you have a reproducer that would be great, I plan to look at it, but my schedule is quite crazy this week and the next
I just published my reproducer: https://github.com/t1/wildfly-otel-demo
It's not super-urgent, but I'd like to suggest in my current project that we should go from our brittle and vintage logging/analytics stack to O11y... and we can't do that without support for GraphQL.
I use WF 28.0.1.Final with the feature pack 2.1.0.Final and the Galleon layers
jaxrs-server
,microprofile-graphql
, andopentelemetry
.When I set
smallrye.graphql.tracing.enabled
totrue
, all calls result in aUnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type Tracer with qualifiers
inInstanceImpl:251
.