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

Polished contributing document #10693

Merged
merged 2 commits into from
Feb 29, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 6 additions & 10 deletions docs/contributing/writing-instrumentation-module.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Loading