# Paraya 7 JAX-RS invalid transaction name + no span captured with @WithSpan **URL:** \ **Category:** APM\ **Tags:** docker, open-telemetry\ **Created:** [February 10, 2026, 2:08pm UTC](https://discuss.elastic.co/t/paraya-7-jax-rs-invalid-transaction-name-no-span-captured-with-withspan/384995 "2026-02-10T14:08:20Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ciment](https://avatars.discourse-cdn.com/v4/letter/c/c37758/32.png) [@ciment](https://discuss.elastic.co/u/ciment)\ **Post date:** [February 10, 2026, 2:08pm UTC](https://discuss.elastic.co/t/paraya-7-jax-rs-invalid-transaction-name-no-span-captured-with-withspan/384995/1 "2026-02-10T14:08:20Z")
Hi, @Sylvain_Juge Based on previous discussion ( [Problem with distributing tracing for Jakarta 10 and payara 6](https://discuss.elastic.co/t/problem-with-distributing-tracing-for-jakarta-10-and-payara-6/372920) ) 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](https://github.com/ciment7/jakarta-test/tree/master) 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](https://us1.discourse-cdn.com/elastic/original/3X/b/3/b39c879c5a92844eacfeddac0fc0fd5b065f20ca.png) 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. ``` ```auto 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](https://us1.discourse-cdn.com/elastic/original/3X/5/f/5f5787258b7fcc0f23510a0557421f911fe0c756.png) For async responses - X-Trace-Id is missing in response headers - see com.ciment.test.jakartatest.TraceIdHeaderResponseFilter Thanks in advance to check this issue. ---
**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\ **Post date:** [February 13, 2026, 5:11pm UTC](https://discuss.elastic.co/t/paraya-7-jax-rs-invalid-transaction-name-no-span-captured-with-withspan/384995/2 "2026-02-13T17:11:52Z")
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. ---
**Author:** ![ciment](https://avatars.discourse-cdn.com/v4/letter/c/c37758/32.png) [@ciment](https://discuss.elastic.co/u/ciment)\ **Post date:** [March 13, 2026, 7:39am UTC](https://discuss.elastic.co/t/paraya-7-jax-rs-invalid-transaction-name-no-span-captured-with-withspan/384995/3 "2026-03-13T07:39:09Z")
@Sylvain_Juge Does a ticket exist somewhere for this issue? I would like to track how this fix is going. Thanks. ---
**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\ **Post date:** [March 17, 2026, 12:42pm UTC](https://discuss.elastic.co/t/paraya-7-jax-rs-invalid-transaction-name-no-span-captured-with-withspan/384995/4 "2026-03-17T12:42:03Z")
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](https://github.com/open-telemetry/opentelemetry-java-instrumentation/) which EDOT inherits from. As a next step I would suggest to - modify the sample application to make it able to use the upstream opentelemetry-java-instrumentation java agent in place of EDOT Java - open an issue with instructions how to reproduce in [GitHub - open-telemetry/opentelemetry-java-instrumentation: OpenTelemetry auto-instrumentation and instrumentation libraries for Java · GitHub](https://github.com/open-telemetry/opentelemetry-java-instrumentation/) - the expected/effective span name can be extraced from the agent logs when you set `OTEL_JAVAAGENT_DEBUG=true` environment variable, this allows to reproduce the issue without kibana (also upstream is vendor-agnostic so other contributors are unlikely to use the same backend as you here). Given there is likely a gap/bug in the upstream opentelemetry instrumentation, the issue will need to be handled there anyway.