JBEAP-26952 / WFLY-19326 removed a bunch of modules from being added to the deployment classpath by the OpenTelemetryDependencyProcessor.

However, the "io.smallrye.opentelemetry" module is needed on the deployment classpath since that contains the CDI provider method providing the OTel Tracer implementation.

The result of this was that deploying a bean using an injected Tracer will not work if only the opentelemetry subsystem is added. See https://issues.redhat.com/browse/JBEAP-27127 for the stacktraces.

This is what happens in the quickstarts, and where the problem was first found (JBEAP-27127) since in the quickstarts we tell people to start the server with standalone.xml, and to run a script adding the opentelemetry subsystem. This is a regression from WildFly 32.0.0.Final where everything works as expected, and the JBEAP-26952 / WFLY-19326 commit is where the failure starts happening.

However, our tests for OpenTelemetry pass in WildFly. They are in the testsuite/integration/microprofile module, which tests against a configuration using standalone-microprofile.xml.

standalone-microprofile.xml contains the microprofile-telemetry subsystem, and it turns out that its MicroProfileTelemetryDependencyProcessor adds "io.smallrye.opentelemetry" to the deployment classpath, which explains the difference in behaviour in the opentelemetry subsystem depending on if microprofile-telemetry is present or not.

Readding the "io.smallrye.opentelemetry" module in OpenTelemetryDependencyProcessor allows the opentelemetry subsystem to be usable again without requiring microprofile-telemetry to be present.