Re: Locators (was: Re: Context: usage recommendations?)

[Stephen McConnell]

Adam Murdoch wrote:

Several more problems with the narrowing approach:

- Forces the container to use a proxy of some kind, regardless of whether the container needs to isolate components. Limits the container's options for scaling down.

The proxy case is only required if:

(a) your mapping in multiple interfaces
(b) your handling backward compatability

I.e. its the component author that is forcing the use of proxies for particular use cases, not the container.

- Prevents the use of the same interface for multiple services (including super-interfaces).

Only if your aggregating interfaces as opposed to definting a single locator that supports one interface derived from another interface. For example, a PhoenixBlockContext could extend AvalonStandardContext. This has impact at the meta level but its a workable proposition then enables interface reuse.

- Prevents delivery of things that are not interfaces (eg File or ClassLoader).

I don't think this is an issue - the object that is proxied is the aurgument to contextualize or service. Things like File and ClassLoader are then accessed via get, or locate, or getWorkingDirectory, etc.

- Prevents additional services from being added during the lifetime of the component.

Disagee - the notion of wether something is dynamic or not should not be prevented by the existance of the proxy. Remember that the dynamic service access is invoked against the proxy - the proxy is not the service your requesting.

- Limits lookup and query mechanisms to cast and instanceof. Prevents us adding additional kinds of lookup and query methods later.

Ok, I'm confussed - have the impression that we are talking about two different things.

Consider the non-proxy core case:

public void service( Locator locator )
{
Object object = locator.locate( "my-key" );
}

Consider the non-proxy typed case:

public void service( Locator locator )
{
MyLocator manager = (MyLocator) locator;
Object object = manager.getSomeObject();
}

Consider the non-proxy Context/ComponentManager/ServiceManager wrapper

ServiceManager manager = new MappedServiceManager();
try
{
manager.put( locator );
manager.put( myService );
manager.put( anotherLocator )
}
catch( DuplicateKeyException )
{
// do something
}

((Serviceable)object).service( manager );


The complex case is where your aggegating a set of locators and your using a proxy to convert this into a single obect that can be narrow to diferent types. That scenario raises the potential for method conflict - but that a build time concern, not a runtime concern.

Cheers, Steve.

On Sun, 8 Dec 2002 06:03 am, Leo Sutic wrote:

Stephen wrote:
>  * Service locator
>
>    This is a new concept that is very similar to the
>    Merlin extension handler.  It a component that provides
>    a plug-in lookup solution that can be narrowed to a
>    particular interface (and can be located by the container
>    using the interface name as the key). A service locator
>    can be applied to the following three areas:
>
>      * context value lookup
>      * service lookup
>      * lifecycle stage handler lookup

If you have two interfaces:

interface A {
  void method ();
}

interface B {
  void method ();
}

and a dynamic proxy (or any class) implementing both interfaces:

class Proxy implements A, B {
   ...
}

Proxy proxy = ...;

The two calls:

((A) proxy).method ();
((B) proxy).method ();

are indistiguishable. This is true even if you are using a dynamic proxy's
InvocationHandler. (In which case they will both be calls to A.method.)

Unlike C#, Java has no way of distinguishing through what interface the
call was made.

I think this makes your idea less useful.

(Yes, I have a proposal of my own, writing it right now...)

/LS

--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>