avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] RE: ComponentManager interface
Date Mon, 18 Feb 2002 20:15:45 GMT
Leo Sutic wrote:
> 
>>-----Original Message-----
>>From: Peter Donald [mailto:peter@apache.org]
>>Sent: den 18 februari 2002 20:48
>>To: Avalon Developers List
>>Subject: Re: [VOTE] RE: ComponentManager interface
>>
>>
>>On Tue, 19 Feb 2002 00:45, Leo Sutic wrote:
>>
>>>>From: Peter Donald [mailto:peter@apache.org]
>>>>
>>>>On Tue, 19 Feb 2002 00:06, Leo Sutic wrote:
>>>>
>>>>>>From: Peter Donald [mailto:peter@apache.org]
>>>>>>
>>>>>>different scope of resource allocation is treated as different
>>>>>>scopes?
>>>>>>
>>>>>But these scopes coexist in the same component, and you assume that
>>>>>there are only two - request and static.
>>>>>
>>>>do i ? Have a look at the javadoc at
>>>>
>>>>
>>/jakarta-avalon/src/java/org/apache/avalon/framework/context/Context.java
>>
>>>So your proposal is basically that we do away with the Contextualizable,
>>>Composable interfaces and pass the CM in a Context object for each
>>>call to a component?
>>>
>>eh?
>>
> 
> That was my reaction, too.
> 
> If you have (as in the javadoc):
> 
> void doMagic( int param1, int param2, Context otherParamsInHere );
> 
> Then the CM goes in the Context, right? You pass the per-request CM
> in the Context, right?
> 
> Now, if a Context is passed in to every method, and if a CM is passed
> in that context, and it is assumed that the context and the CM passed
> in are to be used in that method, then what need is there for Composable
> and Contextualizable?


Where did this come from?

Context can be Application scope, Subsystem scope, or request Scope.

It depends on how you design your system.  Most implementations use
Application and Subsystem scope, but request scope is in the minority.

The CM should *never* be part of the Context.  If you want to lookup
a specific instance of a Component with a Context, you would pass it
as the hint.

Example:

ComponentSelector selector = (ComponentSelector)
                               manager.lookup(MyComponent.ROLE);
MyComponent instance = (MyComponent) selector.select( context );


With the proposals out there for the combining CM/CS into one:

MyComponent instance = (MyComponent) resolver.resolve(Mycomponent.ROLE,
                                                       context);

You pass the request context as the "hint" or policy so the container
can interpret it properly.

Does that make more sense?

It was never conceived to place the CM into a Context object.  (at least
in my awareness)


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message