avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@infogation.com>
Subject RE: ContainerManager and Sub-containers
Date Mon, 03 Jun 2002 16:42:22 GMT
I find myself having a problem with The ComponentSelector, too.  It does not
allow to easlily seperate component development and deployment/assembly
(outside Phoenix).  If an Assembler decides too assemble a system with
component A, B, and C and A and B have the same role and C depends on this
role, then A and B have to be deployed in a ComponentSelector, and C has to
be coded to lookup the role using a second step by first looking up the
ComponentSelector. The component itself is then no black box anymore.  It
can only work if A and B are inside a Selector.  Of course, and that's what
I do, we can check for this and depending where the component is managed
obtain it from and release it to, but the additional code in each component
should not be necessary.  It might be that I'm missing something, though...
I currently use the fortress container and from what I can see in the code
the components are automagically put into a selector based on the configured
id value.  From my perspective, and to allow for easy black box component
coding, it would be a start to have selectors be retrieved by something like
lookup(ROLE + "/selector") and when asking lookup(ROLE) we get the first or
then one with id "default".  So a component when asking for a role it gets
the default implementation because it does not really care.  If it needs to
select it has to explicitly ask for a selector object.  The problem then is
that there might not be a selector available.  At this point the container
must create one dynamically with only one component in it, which is the
default one.  This makes for easy assembly of black box created components,
with keeping the selector architecture.  Of cours you coul also change
framework and introduce a second method into ComponentManager which is
lookup(String role, Object hint) but here we are back again in the
ServiceManager discussion I guess...

Does that make sense? 


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, June 03, 2002 5:31 AM
> To: 'Avalon Developers List'
> Subject: RE: ContainerManager and Sub-containers
> > From: Peter Donald [mailto:peter@apache.org] 
> > 
> > > I think the key is to have the second lookup (to find the 
> > component B 
> > > that is contained in C) standardized via a interface.
> > 
> > Personally I think the exact opposite ;) 
> > 
> > I HATE the ComponentSelector interface and think it is a huge 
> > mistake to use 
> > it. If the ComponentSelector is simply access to a category 
> of avalon 
> > components then I can't see why you can't depend on/lookup a 
> > component 
> > directly. 
> Keep in mind the purpose of the Selector/Manager relationship.
> The selector is much better or more elegant when we have something
> like Cocoon.  The components available for Generation, Transformation,
> or Serialization are many.  Plus it is hard to determine what should
> be the actual mapping to the specified component.  For example:
> Generator.ROLE + "/file"
> Generator.ROLE + "/stream"
> Generator.ROLE + "/foo"
> Truth be told, the File and Stream options can both be used to get the
> same results....
> So how do we choose the suffix safely?  The Selector is better here.
> > ie Consider case where you look up selector with 
> > SocketManager.ROLE then look 
> > up SocketFactory component using "ssl" hint. Why could you 
> > not instead lookup 
> > the ssl factory directly via SocketFactory.ROLE + "/ssl". 
> In this case, it might be just better this way.  You have two options:
> SSL and no SSL.
> > Much easier to do dependency checking, much easier for 
> > component implementer 
> > and gives the assembler much more choice in assembling the system.
> And the more complex ways are having the container take care of it
> all for you.
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

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

View raw message