[webbeans-dev] Re: Hierarchical Managers

Gavin King gavin at hibernate.org
Sat Dec 6 13:45:24 EST 2008


Here's a second draft using definition (2). Take a look at both
drafts, and see which you like better.

Note the undefined behavior for one case in 11.7.1!

Notice that I also slightly rewrote the preamble in section 9.3 for
greater clarity.


On Thu, Dec 4, 2008 at 1:30 PM, Gavin King <gavin at hibernate.org> wrote:
> OK, here's a first draft of the definition of child managers, assuming
> the simpler solution (1).
>
> Please take a look at sections 11.7 and 11.2 and let me know your feedback.
>
> On Thu, Dec 4, 2008 at 1:19 PM, Gavin King <gavin at hibernate.org> wrote:
>> I've discovered a problem with setCurrent(scopeType).
>>
>> What if I called:
>>
>>   child1.setCurrent(BusinessProcessScoped.class)
>>   child2.setCurrent(SessionScoped.class)
>>
>> Then I would have an ambiguity about "which" current manager was
>> intended, since there is no definable ordering between these to
>> scopes.
>>
>> There's two possible solutions to this:
>>
>> (1) Limit setCurrent() to the request scope, and require that the
>> orchestration framework take care of propagation to other requests.
>> (2) Say that if 2 different current contexts have different child
>> managers defined, an exception is thrown
>>
>> Which option do you think we should go for?
>>
>> On Thu, Nov 27, 2008 at 4:30 PM, Gavin King <gavin at hibernate.org> wrote:
>>> On the concall, we made some significant progress with the design for
>>> hierarchical Managers. We decided to develop the following approach:
>>>
>>> (1) web beans belonging to a child manager may have any scope
>>> (2) each child manager has its own set of contexts (there is a
>>> parallel context hierarchy for each scope) that "belong" to, and have
>>> the same lifecycle as, the parent contexts
>>> (3) therefore the web beans belonging to the child are not visible to
>>> web beans belonging to the parent
>>> (4) however, web beans belonging to the parent *are* visible to web
>>> beans belonging to the child
>>> (5) a child manager may be associated with a context by calling
>>> Manager.setCurrent(ScopeType), and is then automagically propagated
>>> with the context
>>> (6) web beans belonging to the child manager may be obtained via EL
>>> evaluation whenever the child manager is in scope, or by directly
>>> calling a getInstance() method of the child manager
>>>
>>> The needed API changes are as follows:
>>>
>>> Manager {
>>>    public Manager createChild();
>>>    public void setCurrent(Class<? extends Annotation> scope);
>>>    public void validate();
>>> }
>>>
>>> Context {
>>>    getChild(Manager childManager);
>>> }
>>>
>>> There is one question remaining open:
>>>
>>> Should it *ever* be possible to access a web bean belonging to the
>>> child manager via a reference that was injected into a web bean
>>> belonging to the parent manager or into some non-contextual object
>>> such as a servlet or MDB?
>>>
>>> For example, we might choose to support this in the case that the
>>> child manager web bean specializes the parent manager web bean.
>>>
>>> Bill, is this a feature that Oracle requires? If not, I'm inclined to
>>> *not* support it in web beans 1.0.
>>>
>>> --
>>> Gavin King
>>> gavin.king at gmail.com
>>> http://in.relation.to/Bloggers/Gavin
>>> http://hibernate.org
>>> http://seamframework.org
>>>
>>
>>
>>
>> --
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>>
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Web Beans 20081206.pdf
Type: application/pdf
Size: 559262 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20081206/d0d08022/attachment.pdf 


More information about the weld-dev mailing list