Yep, relying on zipkin (currently) and maybe later jaeger formats we cover most of the "open" formats but they clearly missed the important part of the spec :(.
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 lun. 28 mai 2018 à 09:00, Mark Struberg <[email protected]> a écrit : > That's why I said that they started at the wrong end! > > MicroServices and distributed computing in general are by definition > language agnostic aka polyglot. > So it's imo plain wrong to start with defining a JAVA API but _not_ > defining the underlying transport mechanism. > > This is like defining the Java API for HTTP but without having any HTTP > specification written down yet. > > And of course they could have just started with a few formats, like e.g. > defining the default names and format for HTTP headers, SOAP envelope tags, > param names for various messaging systems, etc. > The list doesn't need to be final, but with those 3 you will likely > already have covered 98% of all the usage. > But thy them refusing to define this it's yet another lost opportunity. > > Of course it's not yet too late and I still have hopes. > > LieGrue, > strub > > > Am 22.05.2018 um 13:36 schrieb John D. Ament <[email protected]>: > > > > Dont forget that opentracing is protocol agnostic. You can use the same > open tracing libraries to span client, server, jms queues, db calls, etc. > Its not limited to HTTP. Also note my prior email RE vendor integration. > > > > On Tue, May 22, 2018, 7:10 AM Mark Struberg <[email protected]> wrote: > > This is actually the most important part and it is still not defined. > > > > They really started at the wrong end and it seems did not have the same > understanding of portability [1]. > > Or at least they seem to not have any interest to make the impls > exchangeable but just want to push their own impls. > > > > So I'd say we just make the header names configurable and creat an own > default for it. > > > > For completeness sake: the original background can be found here [2]. > > > > LieGrue, > > strub > > > > > > [1] > https://groups.google.com/d/msg/microprofile/YxKba36lye4/c6hGiuuEBAAJ > > [2] > https://groups.google.com/d/msg/microprofile/fSnfHmVb_JA/r8dDnsrqFgAJ > > > > > > > Am 21.05.2018 um 07:49 schrieb Romain Manni-Bucau < > [email protected]>: > > > > > > 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 | Blog | Old Blog | Github | LinkedIn | Book > > > > > > > > > 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 | Blog | Old Blog | Github | LinkedIn | Book > > > >
