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? Marc > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 03, 2002 5:31 AM > To: 'Avalon Developers List' > Subject: RE: ContainerManager and Sub-containers > > > > From: Peter Donald [mailto:[EMAIL PROTECTED]] > > > > > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
