You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2018/05/19 19:27:50 UTC
opentracing update
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>
Re: opentracing update
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@yahoo.de> 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 <jo...@apache.org>:
> >
> > 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 <st...@yahoo.de> 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 <
> rmannibucau@gmail.com>:
> > >
> > > 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 <rm...@gmail.com>
> 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 <rm...@gmail.com>
> 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 <jo...@apache.org> 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 <
> rmannibucau@gmail.com> 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
> >
>
>
Re: opentracing update
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@apache.org>:
>
> 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 <st...@yahoo.de> 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 <rm...@gmail.com>:
> >
> > 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 <rm...@gmail.com> 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 <rm...@gmail.com> 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 <jo...@apache.org> 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 <rm...@gmail.com> 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
>
Re: opentracing update
Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@yahoo.de> 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 <rmannibucau@gmail.com
> >:
> >
> > 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 <rm...@gmail.com> 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 <rm...@gmail.com>
> 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 <jo...@apache.org> 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 <
> rmannibucau@gmail.com> 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
>
>
Re: opentracing update
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@gmail.com>:
>
> 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 <rm...@gmail.com> 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 <rm...@gmail.com> 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 <jo...@apache.org> 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 <rm...@gmail.com> 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
Re: opentracing update
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@gmail.com> 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 <rm...@gmail.com> 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 <jo...@apache.org> 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 <
>>> rmannibucau@gmail.com> 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>
>>>>
>>>
Re: opentracing update
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@gmail.com> 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 <jo...@apache.org> 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 <rm...@gmail.com>
>> 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>
>>>
>>
Re: opentracing update
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@apache.org> 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 <rm...@gmail.com>
> 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>
>>
>
Re: opentracing update
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@gmail.com>
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>
>