John, did you see a standard http format for headers and span payloads? Zipkin one is quite defined but i dont find anywhere something finished for opentracing.
Should we go with zipkin one for now and make it pluggable later? Le dim. 20 mai 2018 20:37, Romain Manni-Bucau <[email protected]> a écrit : > Just got it passing, still need some "prod" work and cleanup but at least > we have a kind of milestone and something to start with. > > > 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> > > > Le dim. 20 mai 2018 à 10:02, Romain Manni-Bucau <[email protected]> a > écrit : > >> 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> >>>> >>>
