-
Notifications
You must be signed in to change notification settings - Fork 4
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
Provide spring autoconfiguration for the API extensions tracer #11
Conversation
@jpkrohling can you review aswell please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't 'spring' be included in the autoconfigure module name somewhere?
} | ||
} | ||
if (observerFound) { | ||
log.info("Use extensions API tracer with observers=" + tracerObservers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe log original tracer somewhere in that message as well, as it might be the last chance to do so 😉 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW: why is commons logging used? Is it an integral dependency already available from Spring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its the preferred logger for spring (boot).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding 'spring' in the name - possibly but just made it longer - not sure.
I don't know whether this is the right place for this. I am still wondering why we cannot avoid this and rather make bindings to GlobalTracer in tracerresolver impls |
} | ||
if (observerFound) { | ||
log.info("Use extensions API tracer with observers=" + tracerObservers); | ||
return tracer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a chance that this tracer
is different than the one currently available via GlobalTracer.get()
, right? Is that on purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its possible - but I think we need to separate the stages - tracer resolution using whatever mechanism is appropriate for the runtime (so Bean in spring), and the next step is to set that in the GlobalTracer for global access.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@objectiser I think @pavolloffay has a point in case there's a pre-registered GlobalTracer
.
I agree with him that that should always take precedence in this case.
I added PR for review: opentracing-contrib/java-tracerresolver#16
As it happens I also agree with you that registering the GlobalTracer
should happen after the resolving (and potential wrapping).
@pavolloffay Not sure if it is the tracerresolver's responsibility to set the GlobalTracer - as mentioned in response to Juca, I think we need to separate the tracer resolution step (TracerResolver, spring Bean, CDI producer, etc) from setting the GlobalTracer. So in spring the TracerResolver is optional - with this PR, even if the user provides their own Bean resolution for Tracer, it will be wrapped. Some other component could then consume the resolved Bean and set the GlobalTracer? |
@objectiser If I understand this PR correctly, it will automatically postprocess any declared Maybe don't try to auto-resolve or auto-register Tracer beans for now (we're using Spring for a reason and there may be specific auto-config jars around for Tracer implementations in the future). What I'd love to see is an additional case of non-wrapping for native support of the API extensions by Tracer implementations (see my comment here: #5 (comment)) |
@sjoerdtalsma This PR is only decorating a Tracer bean resolved using some other mechanism - e.g. opentracing-contrib/java-spring-web#29 has just been merged, which will now by default use the GlobalTracer if no other Tracer bean has been explicitly provided. I'll have a think about your other comment. |
… added 'spring' to autoconfigure artifact id and package
Applied updates based on current comments. As discussed in opentracing-contrib/java-spring-cloud#29 the spring context's Tracer bean will either be provided directly by the app (taking precedence) or be resolved via an existing GlobalTracer registered instance or TracerResolver. However the Tracer bean is resolved, this PR would result in it being wrapped (if observers have been defined). So this PR isn't directly affected by the approach used to resolve the Tracer. |
@objectiser As the outcome of opentracing-contrib/java-spring-cloud#29 it makes sense to include tracerresolver directly in |
@pavolloffay That sounds fine. But as explained that is not relevant in this PR - so is this PR ok as is? |
oh sorry, I though this is auto-config for tracerresolver, my fault. I will re-review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it; a nice way to add the API extensions in spring by adding a simple dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just minor comments
pom.xml
Outdated
<version.io.opentracing>0.30.0</version.io.opentracing> | ||
<version.junit>4.12</version.junit> | ||
<version.org.mockito-mockito-all>1.10.19</version.org.mockito-mockito-all> | ||
<version.org.springframework.boot>1.4.3.RELEASE</version.org.springframework.boot> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor thing could we use 1.4.1?
pom.xml
Outdated
</modules> | ||
|
||
<properties> | ||
<maven.compiler.source>1.7</maven.compiler.source> | ||
<maven.compiler.target>1.7</maven.compiler.target> | ||
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | ||
|
||
<version.commons-logging>1.2</version.commons-logging> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be consumed from spring?
boolean observerFound = false; | ||
APIExtensionsTracer tracer = new APIExtensionsTracer((Tracer)bean); | ||
for (TracerObserver observer : tracerObservers) { | ||
if (observer != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC spring does not autowire null
so this might be not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the produces @bean method returns a null, then it does get included in the set unfortunately. I did have a look for a solution, but couldn't find one. If one is found later then it can be updated in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that it works when autowire
uses required = false
. https://stackoverflow.com/a/26483356/4158442
I was wondering because some time ago I wanted to create a null bean a spring was complaining...
} | ||
} | ||
if (observerFound) { | ||
log.info("Use extensions API tracer to wrap tracer=" + bean + " with observers=" + tracerObservers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I don't know how toString
on this set is defined, maybe just add a log statement on each observer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It currently just outputs a comma separate list of the toString
for each observer - so depends whether the observer reports something meaningful - but it would have the same situation if having separate log statements, so not sure it would be a benefit.
</dependency> | ||
|
||
<dependency> | ||
<groupId>commons-logging</groupId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think this should be consumed from spring. Maybe just import this from spring bom.
@jpkrohling regarding yesterday's discussion. if we were using only |
@pavolloffay @sjoerdtalsma @jpkrohling Thanks! |
This PR is moving the API extensions tracer auto-configure code from opentracing-contrib/java-spring-cloud#15.