-
Notifications
You must be signed in to change notification settings - Fork 324
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
Introduce tracer API within isolated module. #3043
Conversation
👋 @raphw Thanks a lot for your contribution! It may take some time before we review a PR, so even if you don’t see activity for some time, it does not mean that we have forgotten about it. Every once in a while we go through a process of prioritization, after which we are focussing on the tasks that were planned for the upcoming milestone. The prioritization status is typically reflected through the PR labels. It could be pending triage, a candidate for a future milestone, or have a target milestone set to it. |
3314cbc
to
652b540
Compare
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.
This looks great, I only have a few comments/questions.
I think the biggest question here is "do we want to use this API+Impl naming style", because this is not something that we have done so far, so it's a bit new and might need a bit of thought before committing to it.
I think the name duplication is fine as this is an "internal API", there is little ambiguity between the interfaces and their implementations and there is always a 1:1 relationship between them. For very simple types like Scope
or Outcome
we can even avoid creating types outside of the tracer-api
.
apm-agent-core/src/main/java/co/elastic/apm/agent/impl/ElasticApmTracer.java
Show resolved
Hide resolved
apm-agent-core/src/main/java/co/elastic/apm/agent/impl/GlobalTracer.java
Show resolved
Hide resolved
apm-agent-core/src/main/java/co/elastic/apm/agent/impl/transaction/Outcome.java
Show resolved
Hide resolved
@Nullable | ||
<T extends Tracer> T probe(Class<T> type); | ||
|
||
<T extends Tracer> T require(Class<T> type); |
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.
[question] I'm guessing the use-case for those methods might come from next steps in this refactoring, but do we need to have this kind of cast directly available in the Tracer
API ?
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.
This could be added in a next step, but I wanted to add it as part of the minimal API. The idea is to allow for casting the internal tracer of a global tracer to a specific implementation without the global tracer needing to know about a specific implementation.
This way it will still be possible to receive the ElasticApmTracer
, or any other specific tracer implementation from a global tracer.
@@ -148,13 +147,13 @@ void testAutomaticAndManualTransactions() { | |||
void testGetId_distributedTracingEnabled() { | |||
|
|||
co.elastic.apm.agent.impl.transaction.Transaction transaction = tracer.startRootTransaction(null).withType(Transaction.TYPE_REQUEST); | |||
try (Scope scope = transaction.activateInScope()) { | |||
try (co.elastic.apm.agent.tracer.Scope scope = transaction.activateInScope()) { |
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.
[minor] If I understand this correctly, in this case we can just change the original import and not use the FQN, and we will do the same when modifying all the plugins to use the newly created tracer API.
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.
apm-agent-api does not currently depend on the new tracer module, so I wanted to avoid the additional refactoring in the first round.
As for the naming convention: I think it is a good way to evolve the code base as it does not leave any doubt about what APIs are migrated. At some late point, I think it is fair to remove all current interfaces as they are made redundant by the API module. But I would leave this last refactoring to one of the last stages. |
You were faster to push than me, I only have a few tests to add here :-). |
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.
Approve to allow running on CI.
So, if I understand this correctly:
|
Some of the current interfaces contain methods that are only required by internal components, but not by the plugins itself. It would make sense to make the distinction clear, for example by naming it |
The failing unit test struggles with |
Yes, this was fixed with #3044. |
Co-authored-by: SylvainJuge <syl20j@gmail.com>
Alright, I rebased upon main, let's give it another try. Should I squash the commits or are you happy to keep the change set the way it is? |
No need to squash the commits nor rewrite the history, we squash when merging, so it's easier to revert if needed and keeps the |
@elasticmachine run elasticsearch-ci/docs |
What does this PR do?
This PR introduces a minimal, zero-dependency
Tracer
API. This API is a superset of the currentTracer
API which is part of the core module. The API was identified to be the minimal subset of API that is required by the majority of plugins. As a result, plugins can be moved away from depending upon the apm-agent-core module but only rely on this API module. This decouples the plugins from the agents implementation what allows for a cleaner modularization, and it opens for the reuse of the Elastic agent plugins outside of the current implementation of the agent.A large fraction of the changes of this PR are IDE generated. The changes were generated by creating necessary interfaces, and by later pulling members upwards. At the same time, javadoc was moved upwards the interface hierarchy.
Checklist