avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Fri, 11 Jan 2002 19:45:42 GMT

> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Hi Leo,
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > > 
> > > Hi Leo,
> > > 
> > > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > >
> > > > No. Only if you allow the CM to interpret the Context. If you 
> > let the CM
> > > > pass the Context along to a ComponentSelector, there is no 
> > such problem.
> > > 
> > > Man! The ComponentSelector is an "indexing" strategy. 
> > 
> > Paulo,
> > yes, but not CM wide, mon!
> Yes, that is what I miss!!
> > > 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.
>   "...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.

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

> > With my proposal, you would also be certain that
> > the context is interpreted in a predictable way, irrespective of the CM
> > implementation.
> Why is my way unpredictable?
> Is the Map interface unusable and unpredictable?

The Map interface in itself is not unpredictable and not unusable. 

But in this case, the code populating the map and the code fetching things
from the map are separate and not even aware of each other. Thus there must
be an assigned meaning to the key values, and that meaning must be made 
explicit in the contract.

I have not seen you propose any such contract.
> Please try to read what I wrote with a bit more attention, 
> otherwise repeating things again and again will not result in any
> gain.

I'm trying, trust me. You can help me though - I put one question into
my previous email: "However, if you want the ECM (the implementation) to 
manage things other than components, while still letting it implement a 
CM interface, then I'm with you."

So, do you?

What if we had the ServiceManager interface replace the current ComponentManager
interface which was mentioned in this thread previously, and then:

interface ServiceManager {
  Object lookup (String role);
  Object lookup (String role, Context ctx);

interface ComponentManager {
  Object lookup (Object key);

class ExcaliburComponentManager implements ServiceManager, ComponentManager { ... };

interface Composable {
  void compose (ServiceManager sm);

interface Componentized {
  void componentize (ComponentManager cm);

Would this suit your needs? Since you do not intend to use the CM to lookup
what Avalon calls components, having a new interface would solve your
problems, right?


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message