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

Provide spring autoconfiguration for the API extensions tracer #11

Merged
merged 3 commits into from
Aug 10, 2017

Conversation

objectiser
Copy link
Contributor

This PR is moving the API extensions tracer auto-configure code from opentracing-contrib/java-spring-cloud#15.

@objectiser objectiser requested a review from pavolloffay August 8, 2017 14:13
@objectiser
Copy link
Contributor Author

@jpkrohling can you review aswell please?

Copy link

@sjoerdtalsma sjoerdtalsma left a 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);

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

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

@pavolloffay
Copy link
Collaborator

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
opentracing-contrib/java-tracerresolver#15 (comment)

}
if (observerFound) {
log.info("Use extensions API tracer with observers=" + tracerObservers);
return tracer;

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?

Copy link
Contributor Author

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.

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

@objectiser
Copy link
Contributor Author

objectiser commented Aug 8, 2017

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

@sjoerdtalsma
Copy link

@objectiser If I understand this PR correctly, it will automatically postprocess any declared Tracer (spring-) Bean by wrapping the API extensions when necessary?
In this case I like the auto-config part.

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

@objectiser
Copy link
Contributor Author

@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
@objectiser
Copy link
Contributor Author

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.

@pavolloffay
Copy link
Collaborator

@objectiser As the outcome of opentracing-contrib/java-spring-cloud#29 it makes sense to include tracerresolver directly in TracerAutoConfiguration and do not have a separate artifact for it.

@objectiser
Copy link
Contributor Author

@pavolloffay That sounds fine. But as explained that is not relevant in this PR - so is this PR ok as is?

@pavolloffay
Copy link
Collaborator

oh sorry, I though this is auto-config for tracerresolver, my fault. I will re-review.

Copy link

@sjoerdtalsma sjoerdtalsma left a 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.

Copy link
Collaborator

@pavolloffay pavolloffay left a 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>
Copy link
Collaborator

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>
Copy link
Collaborator

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) {
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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);
Copy link
Collaborator

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.

Copy link
Contributor Author

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>
Copy link
Collaborator

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.

@pavolloffay
Copy link
Collaborator

@jpkrohling regarding yesterday's discussion. if we were using only GlobalTracer(not spring context) to propagate tracer across different auto-configs (e.g. feign, jms, web...). There wouldn't we a way to implement this. Or I am not aware of any other way.

@objectiser objectiser merged commit f55a126 into opentracing-contrib:master Aug 10, 2017
@objectiser objectiser deleted the spring branch August 10, 2017 14:54
@objectiser
Copy link
Contributor Author

@pavolloffay @sjoerdtalsma @jpkrohling Thanks!

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

Successfully merging this pull request may close these issues.

4 participants