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

TracingFilter and ServletFilterSpanDecorator #111

Open
williamokano opened this issue Jul 8, 2019 · 5 comments
Open

TracingFilter and ServletFilterSpanDecorator #111

williamokano opened this issue Jul 8, 2019 · 5 comments

Comments

@williamokano
Copy link

williamokano commented Jul 8, 2019

Hi, in this line https://github.com/opentracing-contrib/java-spring-web/blob/master/opentracing-spring-web-starter/src/main/java/io/opentracing/contrib/spring/web/starter/ServerTracingAutoConfiguration.java#L87 the lib is checking for some ServletFilterSpanDecorator decorators. Yesterday I had to create a custom decorator for me and I noticed that if I register my custom decorator, the STANDARD_TAGS is no longer registered due to this checking.

Would not be better if instead of manually checking and injecting we could not simply register it as a Bean and register all the beans?

The problem is that I don't to lose this default behavior, and if I register my custom bean I also have to define standard_tags as a bean to not lose it. So I have do to do something like this:

@Configuration
class DecoratorsConfig {
  @Bean
  public ServletFilterSpanDecorator myCustomDecorator() {
    return new MyCustomerServletFilterSpanDecorator();
  }
  
  @Bean
  public ServletFilterSpanDecorator defaultDecorator() { // this is actually undesired for me.
    return ServletFilterSpanDecorator.STANDARD_TAGS;
  }
}

If someone just don't want to use it, somehow, it could be annotated as @ConditionalOnProperty and be disabled through a property.

I didn't make a PR because I want to hear you guys before to understand this behavior.

@geoand
Copy link
Collaborator

geoand commented Jul 8, 2019

Hello,

That sounds reasonable to me, but @pavolloffay is the opentracing expert here :)

@pavolloffay
Copy link
Collaborator

If somebody whats to provide custom decorators it's his responsibility to provide all the decorators, that is the current deal.

Your proposal makes sense, I think most people just want to add more stuff in the decorators rather than omitting standard tags. If we do this change we should do it globally for all decorators we have.

@whiskeysierra
Copy link

There should still be the ability to completely override the defaults because some tags in the standard are not desired (e.g. http.url exposing path parameters).

@geoand
Copy link
Collaborator

geoand commented Nov 27, 2019

@whiskeysierra would you be interested in contributing that?

@whiskeysierra
Copy link

I'd just leave it as it is, tbh. The current behavior is a) already established and b) allows for all scenarios (combine with standard and completely configure it by hand).

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

4 participants