opentracing-contrib / java-cdi Goto Github PK

The TracerInitializer has a skip procedure, but it might make more sense to move it to a separate artifact, as discussed here: #1 (review)

As https://github.com/eclipse/microprofile-opentracing defines tracing for CDI via @Traced annotation it might sense to use it as API for this project.

This project defines the same annotation - however there might be some semantical differences.

Some issues to consider:

• MP-OT depends on jaxrs APIs https://github.com/eclipse/microprofile-opentracing/blob/master/api/pom.xml#L47
• this project depends on java-ejb https://github.com/opentracing-contrib/java-ejb

cc @jpkrohling

This repository should be vendor-neutral, but at the same time, we don't have a "perfect" world for a consensus. Current discussion points

• Example should provide value to whoever is reading. If we show a screenshot of the traces, we should provide the tools to generate that screenshot, and Jaeger helps with that
• Brave-OT could be added to the example's pom.xml, but it seems that it doesn't work with OT 0.30.0.
• There's no TracerResolver for the MockTracer, so, if the example code would ship with this Tracer, it would need tracer-specific code, which is counter productive: ideally, the example would be about CDI (not MockTracer) and the target application would know nothing about the tracer.

Options:

• Leave it as it is, with Jaeger's Tracer Resolver. Other implementations are more than welcome to send PRs to feature their tracers as well
• Remove a concrete implementation from the example and let the reader add an implementation
• Use MockTracer, adding MockTracer-specific code to the example

This project has a dependency on java-ejb, but that's mostly because the javax.interceptor is reused from that repository, and it's not bringing any EJB-specific dependency. From a naming perspective, it might be better to extract the interceptor into a java-interceptor artifact and reuse it at java-cdi and java-ejb.

Context: #1 (comment)

Before 1.0.0, we need to decide whether or not to keep the current producers, based on feedback from real users.