Package brave.propagation

Class ExtraFieldPropagation.Factory

java.lang.Object

brave.propagation.Propagation.Factory

brave.propagation.ExtraFieldPropagation.Factory

Enclosing class:

ExtraFieldPropagation<K>

public static class ExtraFieldPropagation.Factory
extends Propagation.Factory

Deprecated.

Since 5.11 use Propagation.Factory

Method Summary

Modifier and Type	Method	Description
<K> ExtraFieldPropagation<K>	create(Propagation.KeyFactory<K> keyFactory)	Deprecated.
TraceContext	decorate(TraceContext context)	Deprecated. Decorates the input such that it can propagate extra state, such as a timestamp or baggage.
ExtraFieldPropagation<String>	get()	Deprecated. Returns a possibly cached propagation instance.
boolean	requires128BitTraceId()	Deprecated. Returns true if the implementation cannot use 64-bit trace IDs.
boolean	supportsJoin()	Deprecated. Does the propagation implementation support sharing client and server span IDs.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

get

public ExtraFieldPropagation<String> get()

Deprecated.

Returns a possibly cached propagation instance.

Implementations should override and implement this method directly.

Overrides:

get in class Propagation.Factory

create

@Deprecated
public <K> ExtraFieldPropagation<K> create(Propagation.KeyFactory<K> keyFactory)

Deprecated.

This is deprecated: end users and instrumentation should never call this, and instead use Propagation.Factory.get().

Implementation advice

This is deprecated, but abstract. This means those implementing custom propagation formats will have to implement this until it is removed in Brave 6. If you are able to use a tool such as "maven-shade-plugin", consider using StringPropagationAdapter.

Specified by:

create in class Propagation.Factory

Type Parameters:

K - Deprecated except when a String.

See Also:

Propagation.KeyFactory.STRING

supportsJoin

public boolean supportsJoin()

Deprecated.

Description copied from class: Propagation.Factory

Does the propagation implementation support sharing client and server span IDs. For example, should an RPC server span share the same identifiers extracted from an incoming request? In usual B3 Propagation, the parent span ID is sent across the wire so that the client and server can share the same identifiers. Other propagation formats, like trace-context only propagate the calling trace and span ID, with an assumption that the receiver always starts a new child span. When join is supported, you can assume that when the parent span ID is null, you've been propagated a root span. When join is not supported, you must always fork a new child.

Overrides:

supportsJoin in class Propagation.Factory

requires128BitTraceId

public boolean requires128BitTraceId()

Deprecated.

Description copied from class: Propagation.Factory

Returns true if the implementation cannot use 64-bit trace IDs.

Overrides:

requires128BitTraceId in class Propagation.Factory

decorate

public TraceContext decorate(TraceContext context)

Deprecated.

Description copied from class: Propagation.Factory

Decorates the input such that it can propagate extra state, such as a timestamp or baggage.

Implementations are responsible for data scoping, if relevant. For example, if only global configuration is present, it could suffice to simply ensure that data is present. If data is span-scoped, an implementation might compare the context to its last span ID, copying on write or otherwise to ensure writes to one context don't affect another.

Implementations should be idempotent, returning the same instance instead of re-applying change.

Overrides:

decorate in class Propagation.Factory

See Also:

TraceContext.extra()