Paraya 7 JAX-RS invalid transaction name + no span captured with @WithSpan

Elastic Observability APM
,
1

Hi,

@Sylvain_Juge
Based on previous discussion ( Problem with distributing tracing for Jakarta 10 and payara 6 ) I have already prepared project to test EDOT java agent with payara7.

I have problem with payara 7.2026.1+ EDOT java agent (1.9.0) to see correct transaction.name in Kibana - APM section.

Kibana version: 8.17.0

Elasticsearch version: 8.17.0

APM Server version:8.17.0

APM Agent language and version: 1.9.0 (EDOT java agent)

Browser version: Safari Version 26.2 (20623.1.14.18.4)

Steps to reproduce:

  1. download github project - GitHub - ciment7/jakarta-test
  2. run script - build.sh to build war and run docker-compose.yml - payara+ ELK stack all in one
  3. run script - run_curls_in_loop.sh - to see some samples in kibana
  4. go to browser localhost:5601 and see the result in Kibana→ APM

My expectations to see transaction name properly - GET /hello-world

**
**

image
image2549Ă—1292 248 KB

Actual result, transaction name: GET (no url path)

  • also span is not working correctly - When I use @WithSpan in EJB - I got exception during deployment. When I use CDI class, then deployment works ok, but I see no span in APM for this annotation.

```

 Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method java.lang.IllegalStateException: org.glassfish.deployment.common.DeploymentException: A class fish.payara.microprofile.telemetry.tracing.WithSpanMethodInterceptorBean doesn't have any appropriate constructor

image
image2549Ă—1292 234 KB

For async responses - X-Trace-Id is missing in response headers - see com.ciment.test.jakartatest.TraceIdHeaderResponseFilter

Thanks in advance to check this issue.

2

Hi @ciment , thanks for reporting this.

I have managed to reproduce the issue you have with the transaction name, I think it would be a good first step to focus on this for now.

Your sample application really made it quite easy to reproduce, however I still don’t know what is the cause of this.

What we can see already is that the instrumentation that is creating the transaction is `io.opentelemetry.grizzly-2.3` which means this behavior is probably specific to grizzly implementation and do not happen with other containers.

There is a very similar test setup in quarkus integration tests of the opentelemetry instrumentation, and the expected top span name is `GET /path/to/resource` so I would expect it to work here as well. The observed behavior is also consistent with the Grizzly instrumentation tests where the span name remains “GET” without the path.

I remember seeing a similar case with tomcat where we have:

  • tomcat instrumentation (non servlet) creating the transaction (top-level span)
  • servlet instrumentation that adds extra attributes and modifies transaction name

So, I will try to see if there is something missing in opentelemetry instrumentation for this use-case, with a bit of luck it should not be very hard to fix.

1 Like
3

@Sylvain_Juge Does a ticket exist somewhere for this issue? I would like to track how this fix is going.

Thanks.

4

Hi @ciment , sorry I haven´t been able to get back to this issue as I was busy with other things.

This is not specific to EDOT Java, the instrumentation comes from the opentelemetry-java-instrumentation which EDOT inherits from.

As a next step I would suggest to

Given there is likely a gap/bug in the upstream opentelemetry instrumentation, the issue will need to be handled there anyway.