-
Notifications
You must be signed in to change notification settings - Fork 867
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
Actually fix redisson instrumentation after 3.16.8 release #5201
Actually fix redisson instrumentation after 3.16.8 release #5201
Conversation
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.
Looks good to me. It took me a bit to figure out the CommandData
vs. CommandsData
difference. Does it make sense to combine those into a single class that takes the class and name? Might be a little clearer. 🤷🏻
You still need to have different advice classes for these two - except the method matcher there's pretty much nothing in common. |
Ah yeah, didn't consider that we still need two advices because we don't control creation of them (and just pass the name as a string). Gotcha. |
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.
what do you think about using reflection to call getPromise()
instead?
.../java/io/opentelemetry/javaagent/instrumentation/redisson/RedissonInstrumentationModule.java
Outdated
Show resolved
Hide resolved
015244e
to
0c36f17
Compare
That could work too! I reworked this PR to use |
...agent/src/main/java/io/opentelemetry/javaagent/instrumentation/redisson/RedissonRequest.java
Outdated
Show resolved
Hide resolved
…metry#5201) * Actually fix redisson instrumentation after 3.16.8 release * try MethodHandles * remove unneeded virtual fields
Implemented Lauri's idea of using
VirtualField
s to avoid callinggetPromise()