Is there a way to prevent it from being converted to .classdata?

[zerocooldog]

There are cases where I need to access classes converted to .classdata from an external library.

There is a way to register the class that requires external access in the bootstrap package, but this method cannot be used in this case.

Is there an alternative way to access them in such a case?

[steverao]

You can refer to related design introduction about .classdata. I am not sure about your specific demand. If you want to access them outside the Agent class loader, you need to use Agent class Loader of OTel Java Agent. You can refer to related using case in OTel Java Agent.

[zerocooldog]

@laurit I'm well aware of that. However, I asked because when developing an external library, the already built agent.jar must be added as a dependency. I solved this problem in another way.

Thanks for the answer.

[laurit]

the already built agent.jar must be added as a dependency

Why would you do that? As you have discovered yourself it doesn't work, use the libraries that the agent is assembled from instead.

[zerocooldog]

@laurit

The reasons I used it that way are as follows:

1. I worked on it because I needed custom metric logic in the otel Java agent, but I wasn't aware of the .classdata conversion process. Later, I realized it didn't work when developing in the IDE and importing it.

2. Even if I add the agent project as a dependency, I cannot use the shaded functionality in the actual project I'm working on, so I can't match the packages exactly.

Finally, I could have solved it by writing custom metric logic and using typeInstrumentations to inject bytecode, but in my case, since I needed to capture metric values at various points in the middle of the logic, rather than just at the method start and end, I had no choice but to apply this approach.

In conclusion, I added the class to the bootstrap package and worked on it.

[laurit]

Even if I add the agent project as a dependency, I cannot use the shaded functionality in the actual project I'm working on, so I can't match the packages exactly.

You could use the same approach as the sample distro. Depend on the unshaded agent components and apply the same shading rules as the agent.

[zerocooldog]

@laurit I thought that I could probably reference a the distro/custom module, but since the project I'm currently working on is not heavily dependent on the agent, I ruled out that approach.

Anyway, thanks for your long responses. I'll wrap it up here. :)