fix: add JAXRS API as SR opentracing depends on it but didn't declare it

[loicmathieu]

More info on this Zulip discussion: https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/opentracing.20without.20JAX-RS.20(without.20resteasy)

[ghost]

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

• title should preferably start with an uppercase character (if it makes sense!)
• title should not start with chore/feat/fix/docs but be a proper sentence

This message is automatically generated by a bot.

[Ladicek]

This looks good to me, but I'd love to get another pair of eyes. @radcortez or @kenfinnigan, could you suggest one more reviewer for this? Thanks!

[kenfinnigan]

@loicmathieu can you provide some details about why you were getting a CNFE on @Path when your application wasn't using JAX-RS?

I'm wondering if it's simply a matter of using text class name instead of actual class or something like that?

[loicmathieu]

This dependency is directly used by opentracing-jaxrs (that is a dependency of smallrye-opentracing) and I have a CNFE when using the @Traced annotation on a method.

I cannot extract the stacktrace as the exception was swallowed by the SR reactive messaging processor but if you look at the OpenTracingInterceptor class you can see that at line 35 is call a method skipJaxRs that uses the javax.ws.rs.Path type.

Maybe we can open an issue upsteam about this, but currently JAX-RS is needed in the classpath to use @Traced annotation.

[kenfinnigan]

Thanks for the additional information.

Agree it's worth raising an issue in the upstream project to resolve in a way that doesn't require JAX-RS on the classpath, as it's an issue there.

But I appreciate right now it's currently broken for Quarkus with this use case.

Could you raise an issue upstream and add a comment to the dependency with the issue? We can then track the dependency removal when it's fixed

[loicmathieu]

I openned opentracing-contrib/java-interceptors#15, I'll update the PR to add a reference to this issue inside the pom.xml

[kenfinnigan]

Thanks @loicmathieu!

[Ladicek]

Alternatively/additionally, we could/should fix this in SmallRye. Not sure how big of a deal that is, considering other SmallRye OpenTracing consumers.

[kenfinnigan]

@Ladicek from the brief look I had SmallRye OpenTracing has a dependency on the contrib project to get the ability to process @Traced methods.

Not sure why, but @Traced handling isn't implemented directly.

[radcortez]

Alternatively/additionally, we could/should fix this in SmallRye. Not sure how big of a deal that is, considering other SmallRye OpenTracing consumers.

I was thinking the same. Also, due to OpenTracing status, most likely these upstream projects are not getting much attention.