-
Notifications
You must be signed in to change notification settings - Fork 163
declarative config: declarative config bridge, support Inferred spans #2030
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
base: main
Are you sure you want to change the base?
Conversation
b119720
to
8d60820
Compare
@JonasKunz please have a look |
@jaydeluca please have a look |
...rc/test/java/io/opentelemetry/contrib/inferredspans/InferredSpansCustomizerProviderTest.java
Outdated
Show resolved
Hide resolved
...rc/test/java/io/opentelemetry/contrib/inferredspans/InferredSpansCustomizerProviderTest.java
Outdated
Show resolved
Hide resolved
@jaydeluca please check again |
description = "OpenTelemetry extension that provides a bridge for declarative configuration." | ||
otelJava.moduleName.set("io.opentelemetry.contrib.sdk.config.bridge") |
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.
can you add a README for this module, and describe why it's needed? thanks
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.
done - as agreed, I've also added @jaydeluca as co-component owner
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, makes sense now
would you mind doing this in two steps, first adding declarative config support without creating a reusable bridge component, and then we can circle back to the reusable bridge concept afterwards? if we are going to create a reusable bridge, it might make sense for it to be in core, but that will require more consideration and discussions
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.
without creating a reusable bridge component
- it's actually copied from the agent (and we can re-use it in the agent later) (@laurit reviewed it there)
- not sure what you mean by "without" - do you mean to copy-paste the entire config related logic? or simply move the classes to the inferred spans project?
If we are going to create a reusable bridge, it might make sense for it to be in core, but that will require more consideration and discussions
- core only implements things that are specified - but I'm open to doing that too
- I would suggest doing the move as a follow-up task
This reverts commit 26ce159.
8009c42
to
7da5600
Compare
🔧 The result from spotlessApply was committed to the PR branch. |
8d47d2a
to
1fea00e
Compare
The declarative config bridge has been copied from the agent - eventually, we can use only one, but that's a later step.
Fixes #2029