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

Romain Manni-Bucau commented on OWB-1120:
-----------------------------------------

hmm, maybe this is still too theoric for me but reading it it sounds like you 
guarantee your application to leak or not work concurrency-wise since you will 
basically not be able to control the scope correctly if it already exists or if 
you fallback in a mode you don't really know. This is very very risky to go 
this way.


> 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)

Reply via email to