-
Notifications
You must be signed in to change notification settings - Fork 867
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
Extract javaagent-extension-api from tooling & spi #2879
Conversation
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 |
I'll try to separate all renames/imports into a separate commit tomorrow, that should make reviewing the important stuff much easier. |
eea280c
to
6c8d66b
Compare
Okay, I've managed to split this PR into 2 commits:
|
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
onjavaagent-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 { |
There was a problem hiding this comment.
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
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 Also, how exactly is this interface specific for instrumentation context? |
No, this interface is supposed to hide the actual implementation, not be implemented.
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.
With method names like |
8086767
to
b7bf82c
Compare
Done! The |
@mateuszrzeszutek What if |
Hmm, interesting. If we move the Do you mind if I implement it in another PR? This one is both hard to maintain (conflicts...) and hard to review... |
28a1259
to
0ea9e95
Compare
This reverts commit 7aa517c29e7ddfb02a69121a3693514d4a69aa5a.
0ea9e95
to
0a954b5
Compare
Okay, I moved all muzzle classes except |
👍👍👍
Yes, let's merge this! @iNikem |
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:All javaagent instrumentations are now using this module and do not depend on
javaagent-tooling
directly; everything that was left injavaagent-tooling
is an internal javaagent component that's not supposed to be exposed or used by instrumentation developers.I've introduced the
AgentExtension
interface whichInstrumentationModule
now implements; it also replacesByteBuddyAgentCustomizer
(which kind of resolves #1626). TheAgentExtension
serves as a base for any agent modification/enrichment, including instrumentation.All interesting changes are in
javaagent-tooling
andjavaagent-extension-api
, almost everything else is just import renames.