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