-
Notifications
You must be signed in to change notification settings - Fork 796
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
Suggestions on how to filter Attributes now that forEach takes BiConsumer? #2283
Comments
Here's a rough sketch of using delegate approach to remove a key. This would be a bit nicer with default methods on AttributeBuilder, similar to what #2242 did for Span.
|
Probably not a solution but you can suppress rawtypes as well and remove the type parameter in the first example and it would compile I think. Another idea is providing a |
suppressing rawtypes is a good idea 👍 I'm not clear how |
toAttributes would handle the casting inside to hide it from user. Probably can't use rawtypes there since we would need to do some type checks. |
Closing this, thanks for the suggestions 👍 |
Filtering Attributes in a SpanProcessor used to be simpler when
Attributes.forEach()
had strong typing viaAttributeConsumer.accept(AttributeKey<T>, T)
.E.g. removing an attribute previously:
this same approach is now longer and requires
@SuppressWarnings("unchecked")
:Is the recommendation now to create a
DelegatingAttributes
similar toDelegatingSpanData
that performs the filtering? (I'm going to try this out and will report back)The text was updated successfully, but these errors were encountered: