avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Resolver package--Please post your thoughts
Date Wed, 13 Feb 2002 09:13:36 GMT
On Wed, 13 Feb 2002 05:42, Berin Loritsch wrote:
> I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector approach in the Resolver package. 
> (located in Avalon Framework src/proposals directory). If you find that
> this package does *not* support your needs, or appears clumsy/difficult to
> use, please air your grievances now.

will do ;)

Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay too complex. The reason 
for CM to initially exist was that it was a much simpler interface than any 
of the other naming/directory APIs. I would much prefer to use an existing 
standard API (ie JNDI) than this because the standard while a little complex 
is standard and much easier for new develoeprs to adopt.

This is not simple. Initially when you were taslking about this I thought it 
would be something as simple as

interface ComponentManager
  Object lookup(String role);
  Object lookup(Query query);

class Query
  Query(String role) {}
  void addAttribute( String name, String value );

Such that

lookup( MyService.ROLE ) is equivelent to lookup( new Query(MyService.ROLE) )

If you wanted other attributes to use in lookup you would use something like

query = new Query(MyService.ROLE);
query.setAttribute( "timeToLive", "3" );
lookup( query )

This I think is acceptable because in most cases the users will never need to 
use the more complex construction but if they have to they can.

> Since everyone is keen on removing the necessity of marker interfaces
> sooner than later, I want a smooth migration path.  That means that we need
> a replacement for Component resolution (without the Component interface).

I am all for the minimal change as possible - basically the ServiceManager 
stuff the Stephen proposed.

> It also means that we should do the following:
> * Promote ComponentHandler interface and implementations to Framework

-1 - a concern of the container

> * Provide standard mechanism for registering a Component with a handler
>     - ComponentInfo? (like BlockInfo)
>     - Manifest entries?
>     - Other?

-1 - a concern of the container 

While I would like to see a basic container that leveraged existing designs - 
I don't think it should be in framework that this is done - at least not 
until it is thouroughly specced out and very mature. Keep it in excalibur 
toill then.



| Every rule has an exception,   |
| except the rule of exceptions. |

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