Hi Leo, It is a very interesting proposal and raises less confusion around the use of the Composable interface.
As a generic structure it makes all the sense to consider the CM as a service. I am still ruminating pros and cons but, at the 1st sight, I like it. =:o) Thank you for your time and attention. It ended up being a fruitful discussion and I learned a lot. I hope this goes on. Have fun, Paulo Gaspar > -----Original Message----- > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 12, 2002 2:52 PM > To: Avalon Developers List; [EMAIL PROTECTED] > Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?) > > > > > > -----Original Message----- > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > > Sent: den 11 januari 2002 21:49 > > To: Avalon Developers List > > Cc: [EMAIL PROTECTED] > > Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?) > > > > > > Hi Leo, > > > > > -----Original Message----- > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, January 11, 2002 8:46 PM > > > > > > ... > > > > > > > > > I also mentioned having a replaceable "indexing" strategy that > > > > > you might > > > > > > change for specific Domains. Go back a bit on this thread > > (or in the > > > > > > [RT] Is Poolable Harmful?) and you will find it. > > > > > > > > > > Yes, but if I understood you correctly (and looking below, I > > > > > did), you had > > > > > an indexing strategy that was CM-wide. > > > > > > > > YES! > > > > > > > > > > > > See this paragraph that follows? > > > > > > > > > > However, I just want a CM wide "indexing" strategy, > which on some > > > > > > implementations might even delegate some cases to... > (tadaaaaaaa) > > > > > > ComponentSelectors. > > > > > > > > > > By delegating this responsibility to CS, you allow components from > > > > > different domains to exist in the same CM. If the whole CM has one > > > > > strategy, then you can not do this. > > > > > > > > Ok, I REPEAT: > > > > "...which on some implementations might even delegate some cases > > > > to... (tadaaaaaaa) ComponentSelectors." > > > > > > Which is a non-statement, since the component does not know anything > > > about the component manager implementation. > > > > Why not? > > Why does putting a String and a Context instead of an Object transmit > > more knowledge. > > > > It is all in what you do with it. > > > > I could call lookup like this: > > c = cm.lookup("$#@))(sdjhfkjh"); > > > > Makes no sense and compiles with the > > lookup(String role) > > format. > > > > > > > > > With two lookup methods: lookup(role) and > > > lookup(role,context), you can > > > > > be certain that no matter what strategy is used, you will > > get back an > > > > > interface of type role. > > > > > > > > WHY will you be so certain of that? > > > > > > Because it is specified in the ComponentManager contract. If I > > lookup "X" > > > I know I will get > > > > > > a) an object that is cast-able to X > > > or > > > b) a ComponentException > > > > > > Tell me, Paulo, what would your contract for the ComponentManager > > > interface > > > be? Assume that there is a component Aimpl that needs to > lookup another > > > component implementing interface B. > > > > > > We get: > > > > > > class Aimpl { > > > void doStuff () { > > > ... > > > B b = (B) manager.lookup ( ???? What do I put here ???? ); > > > ... > > > } > > > } > > > > > > Avalon contracts state that the role name == interface name, so > > > now I would > > > look up (String) "B". What is your contract? What do I send to > > > the lookup method to > > > get a B component *irrespective of the CM implementation*? > > > > > > This is the "predictability" I talk about. > > > > > You can have exactly the same contract with the implementation I > > proposed. And you can even have others too, as I have. > > Paulo, > > since it was one of the major things that caused confusion, from now on > I'll refer to a ServiceManager when I mean something that does what > Avalon 4 ComponentManager does, and ComponentManager when talking > about, well, the other thing. > > As for the ServiceManager interface, I think each interface must come with > its own contract. That is the strength of Avalon - since each > interface has > a contract, we can switch implementations dynamically. We can not have > something as fundamental as a SM interface without specifying a contract > for it that all implementations must obey. > > However, services obtained via the SM may have their own contracts. > And I would say that the CM is now a Service that should be obtained via > a SM. > > So, what I would propose is to use the ECM implementation as you > described > below: > > interface ServiceManager { > Object lookup (String role); > Object lookup (String role, Context ctx); > } > > interface Serviceable { > void serve(ServiceManager sm); > } > > interface Composable { > void compose(ComponentManager cm); > } > > class ExcaliburComponentManager > implements ComponentManager > { > ... > }; > > class ExcaliburServiceManager > implements ServiceManager > extends ExcaliburComponentManager > { > ... > } > > But with the following changes: > > Remove: > interface Serviceable { > void serve(ServiceManager sm); > } > > Remove: > interface ComponentManager { > Object lookup (Object key); > } > > Modify: > interface Composable { > void compose(ServiceManager sm); > } > > Then, your code, which needs a ComponentManager would be Composable > and use the SM to lookup a CM that supports *your* domain via: > > sm.lookup (PaulosComponentManager.ROLE); > > and I could get a CM for my indexing strategy via: > > sm.lookup (LeosComponentManager.ROLE); > > where (for example): > > interface LeosComponentManager { > public Object lookup (String uri, Date time); > } > > interface PaulosComponentManager { > public Object lookup (Node node); > } > > class LeosComponentManagerImpl extends ExcaliburComponentManager > implements LeosComponentManager { > ... > } > > class PaulosComponentManagerImpl extends ExcaliburComponentManager > implements PaulosComponentManager { > ... > } > > Thus, > - all contracts are specified properly, and several indexing > strategies can coexist in the same SM. > - each interface has its own well defined contract. > - you can implement any indexing strategy you choose. > > /LS > > > > -- > 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]>
