In order to allow CDI to play well in the general ecosystem, it needs to have SPIs. These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes.

CDI has no way currently to support a framework starting and stopping built in contexts. These built in contexts are not really clear in how they are started, other than the container is responsible for starting them. This means its near impossible for an external library which is not Java EE aware to start these built in contexts. Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases.

These use cases may include:

1. Quartz Scheduler/CDI Integration. A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation. To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active. To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobListeners.html)

2. Camel-CDI. Camel may want to say that during the execution of a route, a request context is active.

3. Netty/CDI (or any arbitrary network based server). During the reception of a message over TCP, a request is active. Likewise, for the entire TCP connection a session context is active.

4. Sparkjava/CDI. Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use.