JAX-WS auto-instrumentation

[espenvis]

Hello,

I am currently instrumenting a legacy JAX-WS SOAP API. The API is running Payara Micro and com.sun.xml.ws:jaxws-rt:3.0.0.

What's unique about my implementation compared to what I see in tests, is the definition of the SOAP webservice. For now I can only provide snippets:

@WebService(name = "FoobarWebService")
public class FoobarWebService implements ArbitraryInterfaceNotWebService {

  @WebMethod(operationName = "get_bar")
  public int get_bar(@WebParam(name = "baz") final Baz baz) {
   return Baz.logic()
  }
}

As you can see, there is no WebService interface, there is just the implementation. However, the implementation does extend an arbitrary, unrelated interface.

From what I can understand, since the arbitrary interface is not annotated as a WebService, the implementation is not picked up as a webservice implementation, despite being picked up as such by the JAX-WS runtime. However, I am not entirely sure.

What I am curious about is what the minimal prerequisites would be to inform the OpenTelemetry instrumenter that this implementation class is in fact a webservice, despite not implementing any particular webservice. Or, if we can explore adding support for this strategy of implementing a webservice.

[espenvis]

Looking further into this, it looks like the issue may not be the lack of a WebService interface. Testing with a minimal interface and implementation, I do not observe any traces.

I find this curious given that the muzzle for jaxws-rt should allow the auto-instrumentation.

I am thinking it may be Payara Micro.

Some additional information:

• JDK: 17 (temurin)
• JAX-WS implementation; Eclipse Metro (jaxws-rt) 3.0.0
• Payara Micro 6.2025.9
• Jakarta EE 10

Also, something that may be noteworthy is that I am also running Jersey 3.1.2 and I can observe traces there, so the Java agent seems to be able to auto-instrument certain things on Payara Micro.

[laurit]

You can view the java agent as a sort of plugin for the jvm, you are not supposed to package it inside your application but rather add it to the jvm command line with -javaagent:/path/to/agent.jar. I deleted all the opentelemetry jars from the application and ran

java -javaagent:/path/to/opentelemetry-javaagent-2.21.0-SNAPSHOT.jar -Dotel.instrumentation.common.experimental.controller-telemetry.enabled=true -Dotel.traces.exporter=logging -Dotel.metrics.exporter=none -Dotel.logs.exporter=none -jar --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED target/application.jar

In the console output there is

[otel.javaagent 2025-10-10 15:36:29:251 +0300] [http-thread-pool::http-listener(2)] INFO io.opentelemetry.exporter.logging.LoggingSpanExporter - 'BogusWebServiceService/get_model' : 7632e2f61623455afda6dd756389f04e 6b491f6d078253ad INTERNAL [tracer: io.opentelemetry.jaxws-metro-2.2:2.21.0-alpha-SNAPSHOT] AttributesMap{data={thread.id=85, thread.name=http-thread-pool::http-listener(2)}, capacity=128, totalAddedValues=2}
[otel.javaagent 2025-10-10 15:36:29:279 +0300] [http-thread-pool::http-listener(2)] INFO io.opentelemetry.exporter.logging.LoggingSpanExporter - '/bogus/BogusWebService/get_model' : 7632e2f61623455afda6dd756389f04e 885d0d290fbbd470 SERVER [tracer: io.opentelemetry.grizzly-2.3:2.21.0-alpha-SNAPSHOT] AttributesMap{data={url.scheme=http, thread.name=http-thread-pool::http-listener(2), network.peer.port=63029, user_agent.original=curl/8.7.1, network.protocol.version=1.1, thread.id=85, http.response.status_code=200, server.port=8080, server.address=127.0.0.1, client.address=127.0.0.1, network.peer.address=127.0.0.1, url.path=/bogus/BogusWebService, http.request.method=POST, http.route=/bogus/BogusWebService}, capacity=128, totalAddedValues=14}

[espenvis]

I am aware of the nature of how it works, if you look at the pom.xml I added it to the Payara Micro Maven Plugin Java commandline options which seems to have instrumented jaxrs (REST), but not jaxws (SOAP). This is likely because JAX-RS is present in the Payara Micro out-of-the-box, but JAX-WS isn't.

I am very happy to see that it works if you pass the agent directly on the JAR, so thank you very much for demonstrating it. I'm a bit embarrassed I didn't give it a shot myself, after having looked at this myself.

So I guess if I was adamant about using the javaagent as a dependency (and passing it to the Payara runtime via the Payara Micro Maven plugin), I'd have to add the jaxws runtime to the Payara Micro instance via the plugin. However, I'll probably see about simply passing it directly to the bundled uber jar.

Thank you for your assistance.

[trask]

So I guess if I was adamant about using the javaagent as a dependency

not sure if it will help, but you could try https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/runtime-attach

[espenvis]

So I guess if I was adamant about using the javaagent as a dependency

not sure if it will help, but you could try https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/runtime-attach

That looks like an interesting way to solve it.

Payara Micro is fully capable of exporting some traces for natively supported libraries like JAXRS, so that always worked flawlessly, and otel.* system properties set on the plugin are properly read and used by the application, so the out-of-the-box experience gave the impression that the Javaagent was doing its thing for JAXWS, but it wasn't, Payara was simply already handling it.

When it came to JAXWS, there was no actual instrumentation because payara-micro:start (or :dev) was never used during debug... which meant the Javaagent wasn't properly attached through the javaCommandlineOptions configuration, seeing as all the plugin does (presumably) is append them to the java -jar call when you run payara-micro:start or payara-micro:dev.

In other words, I do think as long as I use mvn payara-micro:start, my strategy will work. However, I've chosen against this in favor of a more agnostic approach.

I opted to use the maven-dependency-plugin to copy my io.opentelemetry.javaagent:opentelemetry-javaagent Maven dependency to the build directory, it's then later attached in my entrypoint. This means I still get to add the agent as a dependency (which I prefer for version management)

Thank you for the suggestion, though. I definitely appreciate the idea of programmatically attaching the agent to the runtime.

I'll mark this discussion as "answered" seeing as I've got things working. Thank you both for your assistance!