avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Map and Array Dependencies
Date Tue, 01 Oct 2002 12:39:27 GMT
Leo Sutic wrote:
> 
>>From: Peter Donald [mailto:peter@apache.org] 
>>
>>Hi,

> ---------------------- Alt 2
> 
> I think that the use of the postfix magic character(s), # and [], in the
> lookup() call *must* go, since they imply that the returned type (map or
> array or object) isn't part of the role, but can be determined at
> runtime.
> 
> Let the role string, when used in the lookup() call, remain an opaque
> string.
> 
> I should be able to do:
> 
>    MyService[] services2 =
>     (MyService[])sm.lookup( "incoming-queues" );
>  
>    MyService[] services3 =
>     (MyService[])sm.lookup( "outgoing-queues" );
> 
> 
> To return to your example:
> 
>   <dependencies>
>     <dependency>
>       <service name="org.apache.MyService[]"/>
>     </dependency>
>   </dependencies>
> 
> +1 - this means that I have a dependency on an array of MyService.


Concidering that someone (I think it was Stephen) greatly opposed the
semantic of "Selector" to refer to a Service/Component Selector, adding
in additional constraints on the meaning of a lookup key is not a good
idea.

I am missing a large part of the conversation, so I am not sure what
problem the solution is for.  I believe it was Peter D. that suggested
writing an XXXManager for any specific set of components that fulfilled
the same role.  That provides the maximum amount of flexibility in
lifecycle and convenience methods.

I really would like to avoid any more sementics on the lookup key.

As to the example above, the SEDA solution would never require you to
lookup multiple incoming queues.  Instead, the EventPipeline would
automatically gather the events from the different Queues and place
them into the EventHandler for the Stage.  The Stage would then use
a SinkMap to send the outgoing events to the proper location.

I think that is a much nicer solution than looking up the incoming
queues explicitly, and then looking up the outgoing queues and routing
events in that way.


-- 

"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