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.
- Prevents the use of the same interface for multiple services (including
super-interfaces).
- Prevents delivery of things that are not interfaces (eg File or
ClassLoader).
- Prevents additional services from being added during the lifetime of the
component.
- Limits lookup and query mechanisms to cast and instanceof. Prevents us
adding additional kinds of lookup and query methods later.
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
--
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
