[
https://issues.apache.org/jira/browse/OWB-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152752#comment-15152752
]
Shahim Essaid commented on OWB-1120:
------------------------------------
I'm still experimenting with the idea. My custom service creates and tracks the
contexts in the threads and globally, the contexts have locks, etc. so I think
it shouldn't be very hard to track and monitor the contexts in case there are
bugs. There are global identifiers for the contexts that help with identifying
them. I'll have actual code soon to take a look but my current plan is to
create a context namespace for contexts in the container that looks like the
following. The numbers are a global counter and the scope names will be full
class names.
|ApplicationScoped:1|SessionScoped:2 (this is the first session in the first
application scope)
|ApplicationScoped:1|SessionScoped:3 (second session)
|ApplicationScoped:2|....
|SomeOtherTopScope:3|...
The CDI built in scopes have a single top scope (ApplicationScope) and others
are nested under it, and under each other. For these builtin scopes I define a
ContextStrategy as this:
@ContextStrategy
class BuiltinStrategy extends BaseStrategy{
BuiltinStrategy(ApplicationScoped.class, SessionScoped.class,
ConversationScoped.class, RequestScoped.class){}
}
My BaseStrategy takes an array of normal scopes and the array indicates any
required nesting. If it is a top scope, it just takes one. The custom
ContextsService looks for a strategy for a scope and if it doesn't find an
explicitly provided one, it treats it as a top scope and creates a context for
it and tracks it with the appropriate identifiers as described above.
There are few other features, and some corner cases I need to think about, but
that is basically the general idea. It should be able to have some reasonable
default context creation strategy for scopes without having to bother with
creating Extensions, explicit strategies, etc. It is up to the application
developer to decide to further define the scopes (through strategies) and those
definitions are application specific. I'll provide standard definitions
for the standard CDI scopes in a separate jar.
I'll share more code examples when I have them. For now I'll rely on a
recursive call, and a ThreadLocal recursion tag, to BeanManager and return null
from my ContextsService to find any Extension provided contexts.
> 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)
