[jira] [Comment Edited] (OWB-1120) Expose singleContextMap and contextMap from BeanManagerImpl as API

["Shahim Essaid (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OWB-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152752#comment-15152752 ] 

Shahim Essaid edited comment on OWB-1120 at 2/18/16 6:17 PM:
-------------------------------------------------------------

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.


was (Author: sessaid):
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)