| 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:
- "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.)
- "clear" the external storage without destroying the contextual instances (i.e. the context needs to be invalidated before)
- "initialize" the external storage with the map of current instances (e.g. HttpServletRequest in case of request context bound to ServletRequest).
Proposal ManagedContext Add org.jboss.weld.context.ManagedContext#getCurrentInstances() method (name to be discussed) that returns an immutable map of javax.enterprise.context.spi.Contextual to the current instance of the contextual type. Contextual is not guaranteed to be designed correctly as a map key so we might need to return a map of org.jboss.weld.serialization.spi.BeanIdentifier to current instances instead. This method would be used to "capture" the state. By default, the method would throw UnsupportedOperationException. BoundContext Add org.jboss.weld.context.BoundContext#reset() method (name to be discussed) that would accept a map of javax.enterprise.context.spi.Contextual to the current instance of the contextual type (or BeanIdentifier->instance, see above). This method would be used to "reset" the external storage and clear all threadl local caches. By default, the method would throw UnsupportedOperationException. TODO: Typical use case |
