A while ago I tried to implement the MP Open Tracing spec and then gave up. The feature is really something that belongs as a part of the OpenTracing project, and not a vendor implementation capability. You still need a full tracing implementation behind it to work properly, as they are expecting the impl also passes the OpenTracing TCK. The reason they use the mock tracer is to verify the CDI behavior only.
It looks like Pavol has taken it over, he may be able to help guide it a bit better. However, unless we choose to support a specific OT impl, its not worth implementing (and I know how you generally feel about using outside libraries). On Sat, May 19, 2018 at 3:28 PM Romain Manni-Bucau <[email protected]> wrote: > Hi guys, > > I started to implement opentracing spec, it is not finished but overall it > is progressing > but I have a few issues with TCKs which assume we run with the MockTracer > of opentracing instead of a real tracer. > > Should we run with the mock tracer or should we report it as a big deal? > > For now the implementation includes opentracing too so the switch is not a > dependency but we can make it configurable if we want. > > Side note: as a workaround I added not hurting methods in the class (used > by reflection by the tcks) and used CDI to @Alternative in src/test the > beans which would have a bad impact on a prod impl (like the tracer storing > all spans in mem :s). > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> >
