First PR looks good!
Would it be an idea to set a wrapped (or decorated) context controller?
What I'm looking for is a way to start contexts possibly earlier than a specific container implementation normally starts them, and stop them possibly later. If the context is started earlier in say a request, then eventually the container will also start that same context later in the request. If that will throw an exception the request will not proceed, which is of course not intended.
Likewise, when the container stops the context this will thus be too early.
With a wrapped context controller, the startContexts and stopContexts calls can be ignored for those contexts the application (extension/library) wanted to start earlier and stop later. This does of course assume that the container itself will also use this context controller instead of the current proprietary code.
Additionally, the PR does not contain the check anymore to see if the context is already active or already stopped. Is that still intended to be added? This would be particularly useful for code that needs to be portable between different containers, where one container may already have started the context at a given point, where another container has not (catching the exception would be an alternative here but is obviously not so nice).
Another point, what about letting the caller of the startContexts method optionally pass in the objects (or a lambda to obtain them) on which that context primarily depends (if any). E.g. for the request scope, pass in an HttpServletRequest instance.