Context propagation

Hi folks,

@Asynchronous annotation and maybe others execute the method on a different thread which breaks context propagated via thread locals. If these methods use mp-rest-client it breaks tracing or e.g. MDC.

On the spec level there could be a way to reliably propagate context between threads. It could be done by providing custom executor service or maybe via https://github.com/eclipse/microprofile-concurrency

[Ladicek]

I think we want to stay consistent with ConProp as much as possible, including when it comes to ALL_REMAINING.

[Emily-Jiang]

Support integration with context propagation Advantages: +: Tcks - runtime can verify against the tck +: end users knows some runtime might support context propagation +: any methods with @Asynchronous will get some context propagated, defined by Context Propagation. +: It will specify what will happen when both Jakarta EE and Context Propagation are present. Proposed: Context Propagation should win.

The integration is optional. Not portable.

Disadvantages: 1: end users don’t know what contexts are propagated. It varies between runtimes. - User can configure context propagation explicitly via context propagation properties for portability 2: end users don’t which runtimes support this. - Maybe we reword to say the integration is required if both FT and CP are present. TBC 3: More Spec and TCKs to maintain if the end users can’t benefit from this feature.