[
https://issues.apache.org/jira/browse/OWB-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151145#comment-15151145
]
Shahim Essaid commented on OWB-1119:
------------------------------------
Thanks for the tips. I'm looking into these details and I think I'm seeing how
I can do what I need to do.
Should I be looking at the latest source code before making any design choices?
I'm currently looking at 1.6.2 but I see that there is a vote for 1.6.3. Are
the rewrites you are referring to in 1.6.2 or in the upcoming 1.6.3?
Please close this issue if I should continue this discussion on the mailing
list.
I'll summarize what I'm trying to do here in case you can point out some real
problems with my ideas, or help me improve them.
1. All the contexts are stored in in a single ThreadLocal that holds a
ThreadContexts
2. ThreadContexts is a map of id to ThreadContext. There is always a current
ThreadContext, or a new default one is created if the API configuration allows
this.
3. A ThreadContext is a Container (a container is a wrapper around a CDI
implementation, WebBeanContext in this case) and is able to create or return
the current context for the thread for any scope as long as there is a Bean for
that scope in the container. A Container is also the current CDOProvider
4. An API aware thread (i.e. some client code) can set the current
ThreadContext and the thread will operate in that overall context
5. A thread that just does CDI.current() will get the current ThreadContext (a
default one is created if needed) so it looks like it is in a standard CDI
environment
6. My wrapper contexts and context managers are available for injection and a
thread can switch as needed from one container to another, one session to
another, etc. as needed
7. There is read/write locking that can be configured per context or globally
by the client before or while the thread is executing in a context. The
injectable managers allow full control inside the containers, or cross
containers, contexts, etc.
8. Jars on the class path can provide beans for SomeContext,
SomeContextManager, SomeContextStrategy (this can implement context
dependencies such as request needs session, etc.), SomeContextStrategyCallback
and my API will instantiate these beans and build the ThreadContext maps and
context resolution strategies based on the available implementations. With
this, the base Container only has the DependentScoped context implemented and
all others are provided as dependent beans by custom extensions. My API use
these dependentscoped beans to build what it needs, and it re-exposes them as
contextuals where they belong. For example, I have:
@Implementation
@Dependent
MySessionContext extends BaseContextImplementation
This will be used by my API to provide the CDI SessionContext and the instance
will be re-exposed as:
@Producer
@SessionScopped
MySessionContext
so the actual session context is available for injection. Same with the
managers, etc. Managers can be injected to get related contexts. For example,
ApplicationManager is injected to obtain an existing or new session, enter that
session, and repeat as needed until the thread is ready to run some application
specific code in some custom set of contexts.
Any thoughts about this? This sounds too complicated, and I'm not sure how the
extra features might be useful, but I'm implementing reasonable defaults so
that a Java SE client can simply do CDI.current() and the container will be
booted, default session started, default request started, etc. (if these
contexts are available in the container) all without having to do anything
else. The thread can stay in the same request the whole time if it doesn't do
anything else. Shutdown and cleanup will also have reasonable defaults.
At least I'm getting a good understanding of CDI while doing this, and
hopefully something useful will come out of it :-)
> Implement ConversationManagerService to plugin a custom manager
> ---------------------------------------------------------------
>
> Key: OWB-1119
> URL: https://issues.apache.org/jira/browse/OWB-1119
> Project: OpenWebBeans
> Issue Type: Improvement
> Components: Context and Scopes
> Affects Versions: 1.6.2
> Reporter: Shahim Essaid
>
> I'm working on a framework for using OpenWebBeans and it would be very
> helpful to be able to plugin my custom ConversationManager. Currently the
> manager is simply instantiated in WebBeansContext like this:
> conversationManager = new ConversationManager(this);
> Please implement the same logic for loading the ConversationManager as a
> service. I also didn't find an API way for overriding the instantiated
> ConversationManager with a new one after the WebBeansContext is instantiated.
> The initial services constructor parameter doesn't help with this either. I'm
> still new to the OpenWebBeans implementation and I don't think I know enough
> to be able to submit a patch to implement this.
> Did I miss how I can plugin my own manager with the current implementation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
