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

Extract javaagent-extension-api from tooling & spi #2879

Merged
merged 13 commits into from
May 7, 2021

Conversation

mateuszrzeszutek
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek commented Apr 27, 2021

Implementation of (a part of) the module split discussed here: #2779

Sorry for huge PR, but I couldn't really split it further - fortunately most of it are renames and import changes.

All classes used to implement a javaagent instrumentation/extension were extracted to the javaagent-extension-api module:
Screenshot 2021-04-27 at 17 09 27
All javaagent instrumentations are now using this module and do not depend on javaagent-tooling directly; everything that was left in javaagent-tooling is an internal javaagent component that's not supposed to be exposed or used by instrumentation developers.

I've introduced the AgentExtension interface which InstrumentationModule now implements; it also replaces ByteBuddyAgentCustomizer (which kind of resolves #1626). The AgentExtension serves as a base for any agent modification/enrichment, including instrumentation.

All interesting changes are in javaagent-tooling and javaagent-extension-api, almost everything else is just import renames.

@mateuszrzeszutek
Copy link
Member Author

Ouch, this PR has so many changed files that it's almost impossible to review in GH... I'll have to figure out how to split it (at least split it to several commits) after all.

@trask
Copy link
Member

trask commented Apr 27, 2021

Ouch, this PR has so many changed files that it's almost impossible to review in GH... I'll have to figure out how to split it (at least split it to several commits) after all.

It's rendering for me

@trask
Copy link
Member

trask commented Apr 27, 2021

Ouch, this PR has so many changed files that it's almost impossible to review in GH... I'll have to figure out how to split it (at least split it to several commits) after all.

It's rendering for me

I realized that's not what you said, ya, it's a lot of files, how about just a separate commit in this PR for the stuff under javaagent-tooling and javaagent-extension-api?

@mateuszrzeszutek
Copy link
Member Author

I realized that's not what you said, ya, it's a lot of files, how about just a separate commit in this PR for the stuff under javaagent-tooling and javaagent-extension-api?

I'll try to separate all renames/imports into a separate commit tomorrow, that should make reviewing the important stuff much easier.

@mateuszrzeszutek mateuszrzeszutek force-pushed the javaagent-extension-api branch 2 times, most recently from eea280c to 6c8d66b Compare April 28, 2021 18:12
@mateuszrzeszutek
Copy link
Member Author

Okay, I've managed to split this PR into 2 commits:

  • the first one contains (mostly) extracting the javaagent-extension-api module, almost no renames/moving between packages;
  • the second one is moving InstrumentationModule, muzzle and type matchers and is pretty much just renames.

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

thanks for tackling this!!


dependencies {
api deps.opentelemetrySdk
api deps.opentelemetrySdkMetrics
Copy link
Member

Choose a reason for hiding this comment

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

even though it's technically an api dependency, we could consider making it implementation and marking extension-api methods that use it as @Unstable (had similar discussion with @anuraaga last week about instrumentation-api's dependency on metrics)

would just be a compromise if we want to mark the extension-api stable before the metrics api is stable

* This interface contains methods for accessing or creating internal javaagent components that can
* be used to implement an {@link AgentExtension}.
*/
public interface AgentExtensionTooling {
Copy link
Member

Choose a reason for hiding this comment

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

I was having a hard time understanding the need for this as a public API surface, but I think I understand now:

it's needed to break the dependency from javaagent-extension-api on javaagent-tooling

just wanted to check/confirm my understanding...

Copy link
Contributor

Choose a reason for hiding this comment

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

but why is this public?

Copy link
Member Author

Choose a reason for hiding this comment

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

it's needed to break the dependency from javaagent-extension-api on javaagent-tooling

just wanted to check/confirm my understanding...

Yep, it's exactly that. This interface contains everything that we need from tooling/internals in instrumentations.

but why is this public?

The whole interface? It's a parameter of one AgentExtension method which itself is public, and I suppose it does contain some useful things (like access to classloaders) for extension developers.

*
* @see ConstantAdjuster The ASM visitor that does the actual work.
*/
public final class ConstantAdjuster implements AgentBuilder.Transformer {
Copy link
Member

Choose a reason for hiding this comment

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

could be package-protected if moved to same package with InstrumentationModule

@iNikem
Copy link
Contributor

iNikem commented May 3, 2021

I took only a quick look so far and my main concern is the number of public classes. E.g. do we really expect now that users will provide their own implementations of InstrumentationContextProvider? I understand that this is needed for a split between javaagent-extension-api and javaagent-tooling as @trask noted. But extension module uses them, I think, only inside io.opentelemetry.javaagent.extension.instrumentation.InstrumentationModule#extend. Should the body of this method actually live in tooling module?

Also, how exactly is this interface specific for instrumentation context?

@mateuszrzeszutek
Copy link
Member Author

mateuszrzeszutek commented May 4, 2021

E.g. do we really expect now that users will provide their own implementations of InstrumentationContextProvider?

No, this interface is supposed to hide the actual implementation, not be implemented.

But extension module uses them, I think, only inside io.opentelemetry.javaagent.extension.instrumentation.InstrumentationModule#extend. Should the body of this method actually live in tooling module?

That's an interesting idea - we would certainly be able to hide some more things this way. I'll think about how to do it nicely.

Also, how exactly is this interface specific for instrumentation context?

With method names like additionalInstrumentation() - probably not at all? 😂
More reasons to hide it.

@mateuszrzeszutek mateuszrzeszutek force-pushed the javaagent-extension-api branch from 8086767 to b7bf82c Compare May 4, 2021 07:40
@mateuszrzeszutek
Copy link
Member Author

io.opentelemetry.javaagent.extension.instrumentation.InstrumentationModule#extend - should the body of this method actually live in tooling module?

Done! The AgentExtensionTooling interface got considerably smaller, now I'm starting to think that maybe I could get rid of it completely... Please review the current implementation of InstrumentationModule#extend() and let me know what you think - I could use a similar trick to hide those muzzle deps.

@iNikem
Copy link
Contributor

iNikem commented May 5, 2021

@mateuszrzeszutek What if InstrumentationModule should NOT be a AgentExtension? What if there should instead be InstrumentationLoader implements AgentExtension? And its extend method loads all InstrumentationModule, which provide all necessary information to apply each module to AgentBuilder. InstrumentationLoader will live javaagent-tooling module then and will take AgentExtensionTooling with it.

@mateuszrzeszutek
Copy link
Member Author

What if there should instead be InstrumentationLoader implements AgentExtension? And its extend method loads all InstrumentationModule, which provide all necessary information to apply each module to AgentBuilder. InstrumentationLoader will live javaagent-tooling module then and will take AgentExtensionTooling with it.

Hmm, interesting. If we move the ReferenceMatcher to the tooling module (and it's possible if we change the return type of getMuzzleReferenceMatcher() to Reference[]) then we could get rid of the AgentExtensionTooling class.
I kind of liked the fact that we had one SPI less, but that's not such a big deal after all - and we can simplify javaagent-extension-api so that certainly makes it worth it.

Do you mind if I implement it in another PR? This one is both hard to maintain (conflicts...) and hard to review...

@mateuszrzeszutek mateuszrzeszutek force-pushed the javaagent-extension-api branch 2 times, most recently from 28a1259 to 0ea9e95 Compare May 6, 2021 10:32
@mateuszrzeszutek mateuszrzeszutek force-pushed the javaagent-extension-api branch from 0ea9e95 to 0a954b5 Compare May 6, 2021 14:00
@mateuszrzeszutek
Copy link
Member Author

Okay, I moved all muzzle classes except Reference back to tooling and got rid of the AgentExtensionTooling interface. InstrumentationModule still implements AgentExtension, but now the change that @iNikem proposed should be really easy to implement.

@mateuszrzeszutek
Copy link
Member Author

And now the package structure looks like that:
Screenshot 2021-05-06 at 16 02 50

@trask
Copy link
Member

trask commented May 6, 2021

I moved all muzzle classes except Reference back to tooling and got rid of the AgentExtensionTooling interface

👍👍👍

Do you mind if I implement it in another PR? This one is both hard to maintain (conflicts...) and hard to review...

Yes, let's merge this! @iNikem

@iNikem
Copy link
Contributor

iNikem commented May 7, 2021

I moved all muzzle classes except Reference back to tooling and got rid of the AgentExtensionTooling interface

👍👍👍

Do you mind if I implement it in another PR? This one is both hard to maintain (conflicts...) and hard to review...

Yes, let's merge this! @iNikem

I will trust you on that, @trask

@trask trask merged commit 9c7fae3 into open-telemetry:main May 7, 2021
@mateuszrzeszutek mateuszrzeszutek deleted the javaagent-extension-api branch May 7, 2021 06:48
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.

Add distro example for ByteBuddyAgentCustomizer SPI
4 participants