Berin:
Here are my thoughts concerning the Resolver.
Comparative table for Resolver/CM/SM
------------------------------------
CM/SM provides lookup based on String
Resolver provides lookup based on String and Query
semantics.
| args args
| lookup hasThing release
------------------------------------------
Resolver | String - Token.release
| Query Query Token.release
|
CM | String String Component
SM | String String Object
Primary difference
1. Resolver has exposure of a Query argument and Token
return structure exposed on the interface.
2. Resolver releases references via the token
whereas CM/SM release references based on
the object/component reference.
Resolver as an extension of Serviceable/ServiceManger
-----------------------------------------------------
What's missing/different?
1. Lookup on SM returns an object which could be a Token
(no problem), however an additional lookup( Query )
would be needed.
2. hasObject on SM takes an Object as an argument and returns
a single boolean whereas Resolver returns a boolean[]
(that's a problem but could be solved with a different
method)
3. SM allows decommission of a object using remove( Object )
This isn't exposed in the Resolver interface because objects
are removed relative to a Token. This can be handled by
an implementation.
Does is make sense for Resolver to extend Service manager - I
think its workable and makes sense in terms of maintaining the
current CM/SM object model.
interface Resolver extends ServiceManager
{
public Token lookupToken( Query );
public boolean[] hasReference( Query );
}
interface Resolvable extends Serviceable
{
public void setResolver( Resolver resolver );
}
Conclusion
----------
My assumption is that your real needs over and above SM is that
you want to package a collection of references that can be
collectively removed (hence the declaration of Query and Token).
Is that a fair and reasonable conclusion? Can Resolvable re
re-cast as an extension of SM - yes it can. What the
benefit? Maintenance of the CM/SM object model (which I happen
to like a lot, suits my needs, its simple and works well, and
most importantly - ensures a smooth consistent migration path).
Cheers, Steve.
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 12 February, 2002 19:43
> To: [EMAIL PROTECTED]
> Subject: Resolver package--Please post your thoughts
>
>
> 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.
>
> Please either take the approach of fine-tuning the interfaces or
> of providing an alternative.
> It also helps when you state the reasons why you beleive your
> alternative is better :)
>
> 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).
>
> It also means that we should do the following:
>
> * Promote ComponentHandler interface and implementations to Framework
> * Provide standard mechanism for registering a Component with a handler
> - ComponentInfo? (like BlockInfo)
> - Manifest entries?
> - Other?
> * Finalize Resolver framework, or whatever the replacement ends up being
>
> If this seems like a winning migration path, and we really like
> this approach, we can make
> it a part of Framework 4.2 or something like that. It is
> important that we have working
> implementations though.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> 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]>
