avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Fri, 11 Jan 2002 19:10:29 GMT
Hi Leo,

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Friday, January 11, 2002 6:45 PM
> > 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.


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

> 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?
You can fill in something that makes no sense just as well.

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

> With your proposal, there indexing strategy is part of the contract
> between the component, the CM, and the user of the component. With my
> proposal, it is between the component and the user. The CM is utterly
> unaware of the indexing strategy used, and you can have components
> that require different indexing strategies in one CM.

  "...which on some implementations might even delegate some cases 
  to... (tadaaaaaaa) ComponentSelectors."

This means that you can still suite your needs and I can suite mine.

> What if component A requires strategy a, and component B requires
> strategy b? With your method, A and B can never be used together in
> one CM. With mine, they can.

  "...which on some implementations might even delegate some cases 
  to... (tadaaaaaaa) ComponentSelectors."

> > In the end, what I miss is this CM wide "indexing" strategy and I do not
> > see a reason to have 2 lookup methods in the interface.
> > 
> > Notice that in most implementations
> Which isn't good enough. If you have defined a CM interface, then you must
> specify enough to allow one to make assumptions about *all* 
> implementations.

How does lookup(String role, Context ctx) qualify then?

You can still implement a general "indexing" strategy that uses 
ComponentSelectors and to have EXACTLY the same functionality you 
have now (with your very dear ComponentSelectors) you can call:

    lookup("myRole");    // Role with single implementation

or, for the hinted flavor:
    lookup(new RoleAndHintKey("myRole", "myHint"));    

and for the Context flavor:
    lookup(new RoleAndCtxKey("myRole", myContext));    

What are you missing yet?

> This is my main problem with your strategy.
> > calling lookup("role") should work
> > since everybody will try to reuse de default ECM.
> > 
> > 
> > 
> > > Since the domain-specific interpretation is hidden away in the 
> > CS, the CM
> > > need not be changed.
> > > 
> > > I imagine something like this configuration:
> > > 
> > > <myapp>
> > >   <!-- Straightforward -->
> > >   <component role="my.Component" class="my.ComponentImpl"/>
> > > 
> > >   <!-- Selector in use -->
> > >   <selector role="my.SelectedComponent" class="my.ComponentSelector">
> > >     <component hint="key=abc" class="my.SelectedComponentImpl1"/>
> > >     <component hint="key=def" class="my.SelectedComponentImpl2"/>
> > >   </selector>
> > > </myapp>
> > 
> > I hate this selector configuration.
> > 
> > I have situations where I want to declare some of the available
> > implementations in one config file (all the standard components for
> > a domain) and extend that role with some more implementations in 
> > another file (the components specific to ONE application developed
> > for that domain).
> Then that could be solved by merging configurations - I believe Berin was
> up to something like that a while ago for Cocoon.

Why should I go trough that when changing the indexing strategy is
simpler and works better for me?

> > AGAIN: I also want a CM and even some basic ECM decoupled from 
> > domain stuff, otherwise I can not reuse them.
> But you want to decouple the CM interface from the component domain.
> A CM manages Components, as defined by the Avalon framework, and nothing 
> else.

That is exactly its limitation!!! However...

...talking about the Query strategy or using a Context as 2nd parameter
for lookup already turns "Components, as defined by the Avalon framework"
for Avalon 5 into something different from what they were for Avalon 4.

So, since you already agreed on having a different flavour of components
why is it so problematic to use a slighly diferent "syntax" that extends
BUT encompasses the one you defend?

> 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.
> > However, your solution can NOT be less domain aware than mine.
> >
> > I really do not see how what I propose restricts you in any 
> > way.
> It does not restrict me, but it also weakens the contracts I'm using
> to build my components on. It is so flexible as to be unusable, 

Sure, the Map interface and the Context interface are so flexible as to
be unusable too then!

> since
> I have no idea whatsoever what I will get back from a lookup(Object)
> call. 

That must be a personal problem.

I always have a very clear idea of what I will get.

> I'm restricted to passing something in, praying that the indexing
> strategy used in the CM will give me the right interface back. 

Try passing "xj&$#asjdh@!()()%55" as a role. No index strategy 
resists if you pass just _something_. 

It must be something that makes sense, just like with a Context,
and then it works. If you pass an invalid key like, lets say,
"xj&$#asjdh@!()()%55"... you will get a ComponentException.

> With the interface proposed by Berin, I know that I will get the 
> right interface back. 

Try passing "xj&$#asjdh@!()()%55" as a role, like:
  c = cm.lookup("xj&$#asjdh@!()()%55");

> With my proposal, I can even predict (if I have written the CS),
> how the Context will be interpreted.

With my proposal you can predict that too if you keep the default
CM wide strategy of you wrote the one you use yourself. 

And you can keep the CSs too!

Now, maybe I am getting impatient but I would like to get a _valid_
argument for a change.

I have a valid argument: I need the extra flexibility!

And it does not you. In fact you can even wrap such 
NewComponentManager with the old ComponentManager interface and 
it will work just the same.

Please try to read what I wrote with a bit more attention, 
otherwise repeating things again and again will not result in any

Have fun,
Paulo Gaspar

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