By definition:

A context with a certain scope is said to propagate from one point in the execution of the program to another when the set of mapped instances of contextual types with that scope is preserved.

Application context is an example of propagating context. However, other built-in normal scopes (such as request context) usually do not propagate and are only bound to a single thread. It seems there are use cases where propagation makes sense (async jax-rs/servlet).

Weld context management API currently does not allow to:

1. "capture" the current instances easily (javax.enterprise.context.spi.Context#get() can only be used if the set of beans for the given scope is known - requires a portable extension etc.)
2. "clear" the external storage without destroying the contextual instances (i.e. the context needs to be invalidated before)
3. "initialize" the external storage with the map of current instances (e.g. HttpServletRequest in case of request context bound to ServletRequest).

Proposal

Introduce WeldAlterableContext

Add org.jboss.weld.context.WeldAlterableContext interface into API. This interface will be implemented by all contexts supporting propagation and will contain methods to capture current context state in a given thread returning you a collection of all active contextual instances from that context and to clear and set the state of the context, feeding it a collection of contextual instances as its new state.

Introduce helper methods on WeldManager

WeldManager will provide additional means to get hold of all scopes in the application, subsequently allowing user to grab all underlying contexts (implementing WeldAlterableContext).

Compose a human-readable test as an example

Apart from docs, there should be an easy to read test that will show how to propagate contexts (ideally all of them) which will server as a guide for users.