Ok so kind of same raw feeling but not same outcome ;). Let me try to develop what I did today - it is not complete but idea is here.
1. Mp spec module, mp impl as "usual" 2. Opentracing spec module + opentracing impl in the "impl" module (this is why i got this issue). I can split in an opentracing-impl module bit having it all CDI is quite better IMHO and efficient We can surely refactor it and split it cause the main cdi usage is to fire a FinishSpan event which hosts a Span and provide a natural extension point to plug a backend (i intend to just provide a noop and logger impls which would enable kafka, jdbc, .... through appenders). Then next step will be to plug config (optionally with a fallback on system properties) to have a finer config per endpoint (sampling). Does it sound ok? Le dim. 20 mai 2018 03:03, John D. Ament <[email protected]> a écrit : > 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> >> >
