open-telemetry
/
opentelemetry-java-instrumentation
mirror of https://github.com/open-telemetry/opentelemetry-java-instrumentation.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Polished contributing document (#10693)

This commit is contained in:
Steve Rao 2024-02-29 23:29:29 +08:00 committed by GitHub
parent e298000ae5
commit 822abc760b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 6 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/contributing/writing-instrumentation-module.md
View File

@ -344,23 +344,19 @@ compile time for it to work.
Use of `VirtualField` requires the `muzzle-generation` gradle plugin. Failing to use the plugin will result in
ClassNotFoundException when trying to access the field.
### Why we don't use ByteBuddy @Advice.Origin Method
### Avoid using @Advice.Origin Method
Instead of
You shouldn't use ByteBuddy's @Advice.Origin Method method, as it
inserts a call to `Class.getMethod(...)` in a transformed method.
```
@Advice.Origin Method method
```
Instead, get the declaring class and method name, as loading
constants from a constant pool is a much simpler operation.
we prefer to use
For example:
```
@Advice.Origin("#t") Class<?> declaringClass,
@Advice.Origin("#m") String methodName
```
because the former inserts a call to `Class.getMethod(...)` in transformed method. In contrast,
getting the declaring class and method name is just loading constants from constant pool, which is
a much simpler operation.
[suppress]: https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#suppressing-specific-auto-instrumentation