Hi Berin and Leo,
IMO any of those solutions cuts reusability and mix concerns.
Lets take a look at ExcaliburComponentManager - it does a LOT of
very useful and smart stuff besides the specific strategy it uses
to "index" stuff - all that checking that makes it safer and all
that logging that makes much easier to hunt any existing bugs...
...and there could be more.
Maybe that indexing (Mapping) strategy should just be separated.
What is the use?
- Imagine that I want to use a Component Manager to supply global
resources for a scripting/templating tool. It might happen that
I only want to index components by name, whatever their role is.
- Now look at the current situation where most tools are so happy
just working with a String role and a String hint. The context
object is much heavier to build, but on CPU and keystrokes!
This makes those that just want the simple version to pay an
extra cost because of the "complicated guys".
On the other hand, we can have a ComponentManager that implements
the above mentioned functionality accepting a separate indexing
strategy and then wrap it according to our usage. One possible
wrapper would just have the old style interface with:
Object lookup( String role )
{
super.lookup(role);
}
Object lookup( String role, String hint );
{
super.lookup(new RoleAndHint(role, hint));
}
For the scripting guy just:
Object lookup( String name )
{
super.lookup(name);
}
For the localized, "sessioned", complicated guy:
=;o)
Object lookup(String name, Context, ctx)
{
super.lookup(new NameAndCtx(name, ctx));
}
Sorry, but I do not understand why is the ComponentSelector
necessary. You can always achieve the same with a composite key.
You can still use a ComponentSelector as an "implementation"
detail if the indexing strategy is flexible enough.
Obviously, the indexing strategy has to do with the algorithm
used to build the key of the object and that will be domain
specific. And the components for a given domain that need to
access other components from the ComponentManager must know
what indexing strategy is being used.
Application domains can be completely different. I don't give
a sh*t for Sockets and SocketPools as James will and James
possibly does not need to name components as I do. Ant has
probably some other indexing needs.
But all these domains can enjoy a common set of checkings and
logging functionality.
I still see a couple of issues on the configuration step. Mine
works differently and solves some of those issues, but I think
it does not solve them all. However, those obstacles do not
look impossible to beat.
What do you think?
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 10, 2002 3:28 PM
> To: Avalon Developers List
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > interface ComponentManager
> > {
> > Object lookup( String role );
> > Object lookup( String role, Context hint );
> > }
>
> Berin,
>
> the snippet above, I think, would be ideal. I also think that
> the lookup(String, Context) method should work like this:
>
> public Object lookup( String role, Context hint )
> {
> Object component = lookup (role);
>
> if ( component instanceof ComponentSelector)
> {
> return component.lookup (hint);
> }
> else
> {
> return component;
> }
> }
>
> Since the Context may have, for example, HttpRequests, I
> do not want to let the CM interpret the contents of it.
>
> BTW, do we dump the Component interface?
>
> /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]>
