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> >>> >>
