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.
--
Cheers,
Pete
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
