Remove special handling for indy instrumentation#17256
Remove special handling for indy instrumentation#17256laurit merged 1 commit intoopen-telemetry:mainfrom
Conversation
|
@JonasKunz @SylvainJuge can one of you review? thanks! |
| injector | ||
| .proxyBuilder("org.springframework.web.servlet.v3_1.OpenTelemetryHandlerMappingFilter") | ||
| .inject(InjectionMode.CLASS_AND_RESOURCE); | ||
| .inject(InjectionMode.CLASS_ONLY); |
There was a problem hiding this comment.
Does this means that the helperResourceBuilder.register(...) call in registerHelperResources is now used to inject the class as a resource and thus we can use CLASS_ONLY ?
If so, does it means that if we promote the injectClasses method later with #16975 we will thus do the opposite change and use only injectClasses to inject the class as class (proxy) and as a resource ?
There was a problem hiding this comment.
Does this means that the helperResourceBuilder.register(...) call in registerHelperResources is now used to inject the class as a resource and thus we can use CLASS_ONLY ?
yes, now the resource is registered the same way for indy and non-indy instrumentation
If so, does it means that if we promote the injectClasses method later with #16975 we will thus do the opposite change and use only injectClasses to inject the class as class (proxy) and as a resource ?
I want to try out whether we can replace proxy injection with something simpler.
3 participants
Both indy and injecting instrumentation can just expose the original class bytes when needed. This will get us closer to removing the
isIndyModulemethod that we probably won't need (or at least will need to rename it). With indy the proxy and the original class won't match but that shouldn't be a problem. I think we can probably get rid of the proxy and just expose the helper class, that is in the instrumentation class loader, to the application class loader.