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

make rmi instrumentation indy-compatible + add module opener #12585

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

SylvainJuge
Copy link
Contributor

@SylvainJuge SylvainJuge commented Nov 7, 2024

part of #11457

This adds a new ModuleOpener that allows to open modules for indy instrumentation in a declarative way, this will later be required to implement the LDAP instrumentation.

Existing module opens/exports that have been done with dedicated instrumentations like io.opentelemetry.javaagent.instrumentation.rmi.context.jpms.ExposeRmiModuleInstrumentation have been left as-is as they are still relevant for inlined instrumentation. Removing those will be possible once indy instrumentation is applied everywhere.

Related PR in the Elastic APM agent where this approach was initially created by @JonasKunz : elastic/apm-agent-java#2977 (this one being also the one covering the LDAP instrumentation).

This new ModuleOpener is tested indirectly through RMI tests as it fails with indy instrumentation otherwise.

@SylvainJuge SylvainJuge mentioned this pull request Nov 7, 2024
36 tasks
@SylvainJuge SylvainJuge self-assigned this Nov 25, 2024
@SylvainJuge SylvainJuge marked this pull request as ready for review December 13, 2024 17:56
@SylvainJuge SylvainJuge requested a review from a team as a code owner December 13, 2024 17:56
@SylvainJuge SylvainJuge changed the title make rmi instrumentation indy-compatible make rmi instrumentation indy-compatible + add module opener Dec 13, 2024
import java.util.Set;
import java.util.logging.Logger;

public class ModuleOpener {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't there also be a no-op implementation of this class in the non-java9 tooling project?
Otherwise we'll get a ClassNotFoundException on Java 8 I think?

This is likely not covered by CI tests yet because we don't rund the indy tests on multiple java versions.

Copy link
Contributor Author

@SylvainJuge SylvainJuge Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other classes from this module are used with a try/catch(UnsupportedClassVersionError), but here we can also use net.bytebuddy.utility.JavaModule#isSupported, I've added that in 9c251f0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I though that the tooling-java9 project would be bundled as Multi Release Jar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants