[
https://issues.apache.org/jira/browse/OWB-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152705#comment-15152705
]
Shahim Essaid commented on OWB-1120:
------------------------------------
Hi [~romain.manni-bucau], I might be able to do what you say and I'm just not
seeing how exactly do this right now. Still learning :-)
The following is one example that I don't know how to do without directly
accessing those maps:
1. Let's say that there is a Bean in the container of scope @SomeNormalScope
and there might or might not be a contexts registered for this scope through an
Extension.
2. The ContextsService gets called
3. My custom implementation will automatically create a Context for this scope
even if one is not preregistered through an Extension.
4. Before doing 3, my custom service might need to check if there is already an
Extension contributed context before making any decisions about auto creating a
context. I think this is where I need to look at those maps the same way it is
done in the getContext call in BeanManagerImpl.
In terms of whether or not this is CDI, I'm not really sure about that.
However, I think CDI just says that there has to be one active context when it
is needed and my approach is basically doing this but it also allows custom
in-container strategies to override any built-in or Extension provided contexts
(effectively making them inactive), and it also auto-generates contexts if
needed (for any bean that has a normal scoped annotation). I think all this is
almost compliant with the idea that there is only one active context for a
scope at a time. Even if this is not compliant with CDI, I think the context
flexibility I'm experimenting with will help me with building few custom tools
where having a CDI container is very useful.
By exposing these maps as API I didn't mean that they are some official API.
Just an easier and more reliable way to query them or copy them when needed
without having to use reflection or other workarounds.
> 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)
