Adds EntrySplitter for use in w3c specs and secondary-sampling #1193
Conversation
This adds `EntrySplitter` to help handle complex formats such as W3C trace-context efficiently. For example, this has flexible whitespace rules to comply with standards like 'tracestate' which require retaining leading whitespace. See #693
| } | ||
| target.put(key, attributes); | ||
| return true; | ||
| }, keyToAttributes, "authcache;ttl=1;spanId=19f84f102048e047,gateway"); |
There was a problem hiding this comment.
@narayaruna look familiar? :)
| * This is an example of how to parse without allocating strings. This is based on | ||
| * https://github.com/openzipkin/zipkin-aws/blob/master/brave-propagation-aws/src/main/java/brave/propagation/aws/AWSPropagation.java | ||
| */ | ||
| @Test public void example_parseAWSTraceId() { |
There was a problem hiding this comment.
added allocation free trace ID example from AWS
|
Thanks for the look @anuraaga PTAL |
|
@samukce I now realize we don't have rationale for our coding conventions including things you just asked.. I'll add it so it is easier to link to later. We only lightly say a few things here https://github.com/openzipkin/brave/blob/master/HACKING.md but there have been issues in the past particularly about bytecode size. If you aren't careful the jar can grow really big as it is more often people add code without removing code. here are a few related changes which help control size and stay dep free: |
| @@ -18,10 +18,50 @@ thought as it would betray productivity and make this document unreadable. | |||
| Rationale here should be limited to impactful designs, and aspects non-obvious, | |||
| non-conventional or subtle. | |||
|
|
|||
| ## Public namespace | |||
| ## Java conventions | |||
This adds
EntrySplitterto help handle complex formats such as W3Ctrace-context efficiently. For example, this has flexible whitespace
rules to comply with standards like 'tracestate' which require retaining
leading whitespace.
See #693