Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BraveScopeManager throws if Span is not a BraveSpan #99

Open
dschulten opened this issue Jan 31, 2020 · 6 comments
Open

BraveScopeManager throws if Span is not a BraveSpan #99

dschulten opened this issue Jan 31, 2020 · 6 comments

Comments

@dschulten
Copy link

BraveScopeManager.activate assumes that the given Span is a BraveSpan and wants to cast it, throwing otherwise. However, the Span interface can be wrapped by other wrappers, e.g. an ApiExtensionsSpan. Possibly stick to the Span interface in subsequent code or rewrap the incoming Span if it's not a BraveSpan.

@codefromthecrypt
Copy link
Contributor

codefromthecrypt commented Jan 31, 2020 via email

@dschulten
Copy link
Author

I have looked into it and found that it is not as easy, I'll push a sample project.
Related: opentracing-contrib/java-api-extensions#16

@dschulten
Copy link
Author

@codefromthecrypt
Copy link
Contributor

ok so the unit test would use this library I guess. can you do that? main thing is to strictly show why we are permitting this, and also when it can be stopped.

@splatch
Copy link

splatch commented Jun 15, 2020

I've found an case which is fairly simple. I used opentracing-jdbc with zipkin bridge and it works fine as long as I do not modify jdbc tracing to skip datasource pool validation queries.
The error message I get comes from same check:
Span must be an instance of brave.opentracing.BraveSpan, but was class io.opentracing.noop.NoopSpanImpl

I believe that this is simpler to fix, as it seems to be an gap in coverage of bridging.

@codefromthecrypt
Copy link
Contributor

opentracing is a spec, can you please at least raise an issue in their spec repo as it can't be a gap in bridging if it was never said that accepting other types was a requirement.

I think this specific "extension" randomly decided something. It is only fair for them to own that decision by formalizing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants