> -----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]>