Antti, Building a String key can get REALLY complicated. I am not sure if it really is a simplification.
OTOH, if you know how to implement equals() and hashCode() methods, you can build efficient and non-coliding complex keys with ease... ...but then the key parameter should just be a java.lang.Object Have fun, Paulo Gaspar > -----Original Message----- > From: Antti Koivunen [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 13, 2002 6:52 PM > To: Avalon Developers List > Subject: Re: Resolver package--Please post your thoughts > > > While I think something like the Resolver is needed, the current > proposal might be a bit too complex. It, of course, has to be flexible > enough, but also simple, easy, and efficient. > > But why do we need it in the first place? > > - To get rid of the Component interface. > - To provide a consistent way of looking things up. > - To avoid doing the same thing in the future. > > In other words, it has to be flexible enough to suit everyone's needs. I > personally don't care if it's called ServiceManager or whatever (but > Resolver does seem like a nice fit). > > Let's say you want to look up "com.food.FoodFactory:type=ice cream". > Here, the current CM/CS works quite well: > > ComponentSelector cs = cm.lookup(FoodFactory.ROLE + "Selector"); > FoodFactory ff = (FoodFactory) cs.select("ice cream"); > > But consider "com.food.FoodFactory:type=ice cream,flavor=vanilla". OK, > that's a very artificial example, but I'm sure someone will want to do > something similar. I don't think anyone finds SelectorSelectorSelectors > or ManagerManagerManagers very elegant :) > > Enter the Resolver. > > I think it's important to be able to: > > - define each lookup with a single string > - integrate other systems behind the Resolver interface > > So, in its simplest form, the Resolver would work exactly like the > ComponentManager (without its limitations or intermediate > ComponentSelectors). More complex lookups could be defined e.g. using an > URI-type syntax (with custom protocols for different handlers/back-ends). > > Now, about the current proposal, I'm going to question what I don't find > necessary, and I hope nobody gets offended. I'd also like to hear > everybody's opinions on this... > > ---o--- > > 1. Object vs. Component vs. Service > > Am I the only one who finds this separation somewhat artificial? I mean, > why should the component using the Resolver care about where the objects > come from, as long as they match the requested role. Consider the > following: > > component:com.food.FoodFactory > service:com.food.FoodFactory > > vs. > > role:com.food.FoodFactory > > Also, the objects retrieved from JNDI and ORB, are often components (in > the real meaning of the word). > > > 2. Loose Query? > > If we agree that each lookup can be defined with a single string, the > real contract is this: > > Token lookup(String query); > > So what was that ObjectName about? > > - Enforcing a common syntax. > - Improving performance > (e.g. hashCode(), equals(), static final ObjectName = ...) > > To provide this, Query would have to be a concrete class (possibly even > a final one). If parsing of the query is left to the Resolver, the Query > interface isn't really necessary, unless it's used like: > > interface Resolver { > Query newQuery(); > Query newQuery(String baseQuery); > > or something. > > > 3. Look up one OR many, not both. > > I think combining the two just makes things more complex. I would > consider the following: > > lookup(String query); > lookup(String[] queries); > > which would be convenient for both the client and the Resolver > implementation. > > > I hope you find some of this useful. > > (: Anrie ;) > > -- > Antti Koivunen | "Anrie" [un-ree] <[EMAIL PROTECTED]> > --------------------------------------------------------- > Happiness isn't about having everything you want; > it's about wanting everything you have. > --------------------------------------------------------- > > > -- > 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]>
