-
Notifications
You must be signed in to change notification settings - Fork 839
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
Extends TextMapGetter with GetAll() method, implement usage in W3CBaggagePropagator #6852
base: main
Are you sure you want to change the base?
Extends TextMapGetter with GetAll() method, implement usage in W3CBaggagePropagator #6852
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6852 +/- ##
============================================
+ Coverage 90.28% 90.29% +0.01%
- Complexity 6588 6593 +5
============================================
Files 729 730 +1
Lines 19768 19773 +5
Branches 1944 1947 +3
============================================
+ Hits 17847 17855 +8
+ Misses 1327 1324 -3
Partials 594 594 ☔ View full report in Codecov by Sentry. |
* @return the first value of the given propagation {@code key} as a singleton list, or returns an | ||
* empty list. | ||
*/ | ||
default List<String> getList(@Nullable C carrier, String key) { |
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.
Perhaps using List<String>
isn't the best option. Maybe Iterable<String>
as used in keys
or Iterator<String>
would work better? When using List<String>
and carrier is HttpServletRequest
where getHeaders
returns Enumeration
you'd have to copy the enumeration to list with Collections.list(carrier.getHeaders(key))
. When using Iterator<String>
you could skip copying the enumeration to list with
Enumeration<String> enumeration = carrier.getHeaders(key);
return new Iterator<String>() {
@Override
public boolean hasNext() {
return enumeration.hasMoreElements();
}
@Override
public String next() {
return enumeration.nextElement();
}
};
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.
Yes I agree Iterator<String>
is a better choice given the use of Enumeration
in HttpServletRequest
. I had just copied @jack-berg's implementation from #6837. Will update once we get alignment with Jack.
In terms of the name of the new method, getList
also would no longer make sense. Possible names could be getIterator
or getAllValues
, let me know preference.
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.
Hmm... iterator is easier / less allocation for some TextMapGetter
implementations, but (slighty) worse ergonomics for callers.
Given this, I think iterator is the better choice since we expect most (all?) propagator instances to be maintained by opentelemetry, and its fine for us to have slightly more burden to improve performance.
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.
Cool, I've changed it to Iterator
. I've also renamed the method to getAll()
* @return the first value of the given propagation {@code key} as a singleton list, or returns an | ||
* empty list. | ||
*/ | ||
default List<String> getList(@Nullable C carrier, String key) { |
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 might be necessary for us to add this in an experimental fashion, rather than jumping straight to the stable API.
For example, we could have an ExtendedTextMapGetter
interface in opentelemetry-api-incubator
or in an internal package of opentelemetry-context
. Then, W3CBaggagePropagator
could check if (getter instanceOf ExtendedTextMapGetter)
and adjust its behavior accordingly.
If we do this, I think it would have to go in opentelemetry-context
instead of opentelemetry-api-incubator
since W3CBaggagePropagator
doesn't have access to opentelemetry-api-incubator
.
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.
Makes sense to me
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.
Ok, this is done - please take a look
…using new getList() method on the TextMapGetter. Includes tests.
b3f4af6
to
6f13bfb
Compare
…etter, as per review. Also changes the return type of the method to Iterator<String> as per review, and renames the method to getAll(). Tests are also adjusted
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
package io.opentelemetry.context.internal.propagation; |
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.
package io.opentelemetry.context.internal.propagation; | |
package io.opentelemetry.context.propagation.internal; |
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 think this looks great.
Implements proposed spec changes in open-telemetry/opentelemetry-specification#433 and #6837
getList()
method toTextMapGetter
, with default methodW3CBaggagePropagator
to handle multiple headers for baggage, using newgetList()
method.The vast majority of HTTP server implementation are able to return multiple header values, including the commonly used
HttpServletRequest
. I have published this branch to my local maven and demonstrated it's usage in the Spring Web MVC instrumentation module, which uses theHttpServletRequest
interface. See here: open-telemetry/opentelemetry-java-instrumentation#12581