[
https://issues.apache.org/jira/browse/OWB-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152797#comment-15152797
]
Shahim Essaid commented on OWB-1120:
------------------------------------
More theoretical details to get some feedback :-)
Basically, the default ContextsService builds a scope tree structure and a
scope can only exist in one place in this tree. The default place for an
undefined scope is at the top under the tree root. Any ScopeStrategy can adjust
how a scope fits in this tree (session under application, etc.) and the tree is
validated on initialization.
There is a tree of contexts that is built up as needed by using the same scope
names from the scope tree and a counter, (and few name aliases to make the IDs
more user friendly). When a tread needs a context, my framework looks in the
thread to see if it is already somewhere in the context tree and creates or
finds the needed sub context (and any parents if needed) based on some
defaults, rules, name aliases, etc. The global identifiers for these contexts
are the path from the root of the context tree, as a simple string, that gets
added to the ThreadLocal to indicate that that context is active for the thread.
All the contexts in the context tree have read/write locks, a thread can only
lock from, and unlock to, the root so no deadlocks should happen. On locking
and unlocking, the context IDs are put in the thread local to attached and
detach the thread from the contexts. I think it should be easy to do this and
> Expose singleContextMap and contextMap from BeanManagerImpl as API
> ------------------------------------------------------------------
>
> Key: OWB-1120
> URL: https://issues.apache.org/jira/browse/OWB-1120
> Project: OpenWebBeans
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.6.2
> Reporter: Shahim Essaid
>
> My custom ContextsService needs to lookup contexts from the singleContextMap
> and contextMap from BeanManagerImpl. The current implementation doesn't allow
> this and it fully controls the order of context lookup:
> 1. Check the service.
> 2. Check singleContextMap
> 3. Check contextMap.
> In my custom service I'm implementing a default context resolution strategy
> (that implements flat or nested contexts) and it can be configured to do the
> following:
> 1. Always use the built-in context resolution strategy.
> 2. Look in the CDI container for any provided strategies, and then use
> built-in if needed
> 3. Check for any Extension provided contexts and decide to override with
> container provided or built-in strategy.
> 4. etc.
> The BeanManagerImpl doesn't expose the custom context maps
> on their own to help with this. I can use reflection or make another call to
> getContext() and return null from my service to find other contexts but a
> well defined API might be useful; at least to be able to get copies of those
> maps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
