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 17:18:31 GMT
Hi Leo,

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Friday, January 11, 2002 4:35 PM
> 
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > 
> > > -----Original Message-----
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > 
> > > But the difference is between ONE contract for ALL ComponentManagers
> > > and potentially ONE contract for EACH ComponentManager.
> > 
> > I NEVER believe one size fits all.
> > I ONLY believe maximum ease of reuse.
> 
> I read that you are not interested in changing the CM interface, 
> but rather
> to refactor the ECM implementation. As I said in a previous mail, this is
> something entirely different.

Actually, I am interested in changing BOTH.
  
> > > I think Berin's suggestion - with a role followed by an 
> optional Context
> > > is ideal. Then, by allowing the context to be interpreted by a
> > > ComponentSelector, we decouple the Context interpretation from the CM.
> > 
> > It is a different "syntax" with the same problem:
> >  - If your component that uses the ComponentManager does not know how to
> >    fill the right values on the Context, everything fails in exactly the
> >    same way as it would fail with the wrong type of Component.
> 
> No. With you approach the interface to the CM will change, making it
> necessary to have Composable, AdvancedComposable, etc. interfaces where
> each interface specifies a compose() method taking the corresponding
> CM interface as single parameter. Now, with one interface per domain, 
> it just won't scale at all.

NO. Just one Composable but just one lookup method for the CM:
  Object lookup(Object key);

Anyway, read what I said here:
> >  - If your component that uses the ComponentManager does not know how to
> >    fill the right values on the Context, everything fails in exactly the
> >    same way as it would fail with the wrong type of Component.

FIRST
When you change Domain your Component always needs to know how to deal
with the CM for that domain, either by filling the right values in a Context
for this lookup format:
  Object lookup(String role, Context ctx);

or by using the right Object for this one:
  Object lookup(Object key);

SECOND
I just say that a CM for given domain migh just wrap/extend the ECM
to provide simpler to use lookup() methods for the CM clients.


> >    So, both the Component and the CM still must be aware of its domain 
> >    specifics.
> 
> 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. 

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.

However, I just want a CM wide "indexing" strategy, 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 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).

Using a single Map to store the components and changing the strategy
to build the key makes changing configuration schemes much easier
and the while CM more flexible... and you can still have 
ComponentSelectors if you like.

You just need to have Keys with a correct hashcode() and equals()
implementation... which even java.lang.String has ...and a 
RoleAndContextKey class can have too!

 
> Now:
> 
>   lookup("my.Component") => my.ComponentImpl
> 
>   Context ctx = new DefaultContext ();
>   ctx.put ("key", "abc");
>   lookup("my.SelectedComponent", ctx) => my.ComponentImpl1
> 
>   ctx = new DefaultContext ();
>   ctx.put ("key", "def");
>   lookup("my.SelectedComponent", ctx) => my.ComponentImpl2
> 
> This means a strengthening of the contract between CS and CM, but 
> it completely
> decouples the CM from domain-specific stuff.
> 
> /LS

AGAIN: I also want a CM and even some basic ECM decoupled from 
domain stuff, otherwise I can not reuse them.

THEN I want to be able to specialize it more then I can now.

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.


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>


Mime
View raw message