Ryan Shaw wrote:
>
> Stephen wrote:
>
> ||| > What if there are many implementations for the same role,
> ||| > and only some them are poolable. Shouldn't it be possible
> ||| > to switch the implementation without changing the client
> ||| > code?
> |||
> ||| I agree completely with the scenario objective. I don't think
> ||| the consequences of the convenience support are justified. An
> ||| implementation of ServiceManger that supported "release" on
> ||| the grounds that it is auto-magically handling recycled
> ||| components would require something like a foralll embedded
> ||| pools and selectors - release this object if you have
> ||| a reference to it. Given a choice between forcing clients to
> ||| take responsibility for knowing for service procurement source
> ||| type, as opposed to generic simplification at the framework
> ||| level, in this particular case my preference is to push this
> ||| burden onto the client for the sake of framework integrity.
>
> Could you expand on this argument a little further? I consider the ability
> to transparently move between Factory, Pool, and Singleton implementations
> of Components with changing code to be a BIG plus. I'd be sad if it was
> jettisoned.
Factory and Singleton types are equivalent - the issue is with
Pooled services. When acquiring a pooled service you need to
supply a token (something to identify a usage of the supplied
object). This means that a "release" method on ServiceManager
makes no sense unless we modify ServiceManager to take a token
argument on the lookup operation. As soon as we introduce an
Object argument on lookup we throw away transferability of
ServiceManager implementations because Object can be anything
and semantics of "anything" is undefined beyond
System.getHashFor( object ) and you cannot assume that an
object identified by said hascode is only requesting the service
once. Definition of a Token would help resolve that issue by
providing semantics that state that a Taken represents a unique
identifier of a service consumption instance (which is different
to an identifier of the consuming object instance). However, we
are still stuck with the downside of the introduction of an
additional operation of ServiceManager that has questionable
integrity. A possible way around this is to defer the issue to
a ServiceResolver discussion after core interface are
settled.
Here is an example of a revised ServiceResolver definition
following on from my earlier email to Antti earlier today.
interface ServiceReclaimer // abstract
{
void release( Object object );
void releaseAll( Object token );
}
interface ServiceResolver
extends ServiceManager, ServiceReclaimer
{
// convenience selector methods
Object lookup( String role, Object policy );
boolean hasService( String role, Object policy );
// convenience pool methods
Object lookup( Object token, String role );
Object lookup( Object token, String role, Object policy );
Object lookup( Object token, String role, Object policy, Object
criteria );
}
Let me know what your impressions are.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
