Berin, Thanks for the patient help. It finally clicked. Also I finally figured out why I still keep needing to have the "Selector" explicitly in the role definition in roles.xconf at least for some roles. Until I complete the migration, some of our components that are also component factories are using ComponentManager to lookup roles and that's where the conflict is coming from.
Anyway....I'm a happy camper making progress now! Thanks a bunch! Shash ----- Original Message ----- From: "Berin Loritsch" <[EMAIL PROTECTED]> To: "Avalon framework users" <[EMAIL PROTECTED]> Sent: Monday, October 14, 2002 7:17 PM Subject: Re: Fortress config file format > Shash Chatterjee wrote: > > Berin, > > > > I could use a little more explanation. The example for Fortress doesn't > > help at all in this regard, I apologize for asking for so much detail! > > > > Let's say I am going to implement this format in system.xconf: > > > > <a-things><a-thing1/><a-thing2/></a-things> > > <b-things><b-thing1/><b-thing2/></b-things> > > > > I want to use the same selector class for selecting the 2nd-tier components, > > so do I specify that in the roles.xconf file as this (which doesn't work, > > when I tried): > > <roles> > > <role name="...AThingsSelector"> > > <component shorthand="a-things" class="...MySelector" handler="..."> > > <component shorthand="a-thing1" class="..." handler="..."/> > > <component shorthand="a-thing2" class="..." handler="..."/> > > </role> > > <role name="...BThingsSelector"> > > <component shorthand="b-things" class="...MySelector" handler="..."> > > <component shorthand="b-thing1" class="..." handler="..."/> > > <component shorthand="b-thing2" class="..." handler="..."/> > > </role> > > </roles> > > > > So the questions are: > > - The role name should have the "Selector" appened so that it matches > > the lookup? > > No. The role name should be the role name. In your example, it would be > <role name="...Athing"/> > <role name="...Bthing"/> > > When you look it up, you use the "Selector" like this: > > ServiceSelector selector = (ServiceSelector) manager.lookup( "...AthingSelector" ); > > Fortress knows that the component needs to have the components as a selector. > This works when there is only one component available or several. > > > - A component with the Selector class should be specified for each role > > (MySelector)? > > No. THe return value as a selector is automatic, > > > - Can the same Selector class name be used for each role that has > > selectable-components? > > ?? I don't get you here. A ComponentSelector or a ServiceSelector has all > components that satisfy the same role. It is a way of choosing which one. > > > - Can that selector class be FortressServiceSelector? > > It already is. Nothing more needs to be done. > > > - I see that there is special handling for "select" and "default" hints > > in AbstractContainer.addComponent(), but where is that specified? > > It is automatic. > > > > If I can then lookup the Selector, I think I am home free from there, I > > could either override DefaultContainer's configure, or have the > > ServiceSelector's configure load up the second-tier, nested components in > > its configure method? Correct? > > There is no need for a second-tier. However, if you want one, you have > to extend DefaultContainer's configure, and just addComponent(....) for > each instance. It's that easy. Just make sure the id="" has the name. > > > > > Shash > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > 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]>
