avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Mon, 17 Jun 2002 15:58:28 GMT


Stephen McConnell wrote:
> 
> 
> Nicola Ken Barozzi wrote:
 >>
>> I think that a sub-role is general enough to be regarded as not being 
>> container specific.
>>
>> Call that subrole, constraint2, or whatever, but what you say is correct. 
> 
> I would really prefer that we call it a *constraint*.  It is something 
> that is supplied by a conponent to a container that the container must 
> fulfil.
> Sub-role just means something less defined that a role :-)

+1  I used sub-role to try and convey the idea that it was more a "role" 
than a simple "hint". Constraint is much better.

So

what=role
how=constraint

Makes perfect sense to me :-)

>>>> 1) Role: what to do: interface (dependency) 
>>>
>>>
>>>
>>> Can be declared in the type meta-info (so interface name can be 
>>> expressed as a opaque key).
>>
>>
>>
>> I still think that opaque kwys should be interfaces, or the contract 
>> remains too loose.
>> But I don't have *that* strong feelings on it. 
> 
> Keep in mind that I'm looking at this from the containers point of view. 
> I am serviceing a consumer object - which means I know the interface 
> alredy and supplying me with the interface name is academic.  When you 
> add themeta-info into the picture, the container can be much more 
> responsible about doing what is required - the only change is *where* 
> you declare the interface string  (dependecy meta-info declares it as 
> part of the component contract - or - as a part of a lookup argument 
> declares it to a particular type of container what supports that),  In 
> fact, I would consider the meta-info approach much more structuraly 
> sound because you can validate things without the expense of instanting 
> the compoent.

Hmmm... since I cast the Object I get to (RoleInterface), I personally 
regard using that as a role more clear.

(MyRole) myimpl = sm.lookup(MyRole.class);

is much more clear IMHO than

(MyRole) myimpl = sm.lookup("role-1");

Whatever hiding my container does, ultimately I need that cast, so the 
major decoupling I have by not supplying it goes unused.

>>>> 2) Sub-Role: how to do it: behaviour on environment (dependency) 
>>>
>>> Resolution of the interface via the meta-infomation already provides 
>>> us with access to a dependecy declaration.  This dependecy 
>>> declaration can include policy - i.e. specific constraints that 
>>> consumer component requires to be fulfilled by a container when 
>>> making an instance selection.  Policy declared inside a dependecy 
>>> declaration implies that the consumer component has knowlege about 
>>> the type of supplier component. This implies a family of components 
>>> and basically the introduction of policy handlers types that are 
>>> recognized by all containers. If the policy is something that is 
>>> unrelated to a consumer component dependency declaration (i.e. 
>>> not-declared in dependecy meta-info), then, and only then, you are 
>>> introducing additional semantics into the process of a component 
>>> lookup.  In this scenario, a lookup( String opaque, Constraint  
>>> constraint ) would be required in order for the container to 
>>> differentiate between the identification of candidate supply 
>>> components (using the opaque string), and selection of a single 
>>> component from the candidates using the supplied constraint).
>>
>> Yes, yes, yes! Hey, can we say that the message got across? :-D 
> 
> Let's just say that there is some clarification. :-)
> But - I have real concerns about extending lookup to support non-type 
> based constraints - in fact (for the moment) my feeling is that this is 
> point where the client component should be requesting a service that 
> specifically suports non-type selection (i.e. its not a container problem).

Hmmm...

What do you mean by "suports non-type selection"?

>>>> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>>>>
>>>> The name "hint" used by ECM is misleading, since Cocoon hints are 
>>>> not something that can be ignored.
>>>>
>>> Which basically means (presumption mode on) that your doing 
>>> sufficient setup in Cocoon to make sure that the ECM hint resolution 
>>> is always sucessfully resolving your supplied policy directive 
>>> (constraint).
>>
>> Yes.
>>
>>> Am I getting closer ?
>>
>> I think you've got what I mean :-D
>>
> :-D

As someone has implied, we are basically putting a special 
ConstraintBasedSelector in Lookup phase.

This gets rid of the Selector but moves the problem upwards...

Personally, I would prefer this rather than having a Selector...

Hmmm...

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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