Leo,
Leo Sutic wrote:
>
<skip/>
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role );
> Object lookup( Object token, String role );
>
> Object lookup( String role, Object policy );
> Object lookup( Object token, String role, Object policy );
>
> void release( Object object );
> void releaseAll( Object token );
> }
>
> where the policy object is passed along to the selector if present?
This is a little better, but the following might be easier to implement
efficiently:
interface ServiceResolver
{
Object lookup( Token token, String role );
Object lookup( Token token, String role, Object policy );
void release( Token token, Object object );
void releaseAll( Token token );
}
or just:
interface SeviceResolver
{
Object lookup( String role );
Object lookup( String role, Object policy );
void release( Object object );
}
> Before I go and vote for this one, I would also like to hear more
> about Peter's release-less version. If that one works, we could have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object policy );
> }
I'm afraid this would only work for thread-safe services because of the
following fundamental issue (a quote from my previous mail to Peter):
"Stating that the resources will be released at the end of the request,
just moves the "token creation" to a higher level. Only the component
using the resource knows exactly when to release it, so for optimal
performance, there must be a way for the component to indicate this
(e.g. by calling release()). The container is then free to take any
action it sees fit, so the clear IOC remains."
One way around this would be to use something like:
interface ServiceManager
{
Object invoke( String role, String operation,
String[] signature, Object[] params );
}
But IMO this has WAY too many other implications.
So, it looks like we need release(), the question is where...
(: A ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
