Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Adam Murdoch <adammurdoch@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: Locators (was: Re: Context: usage recommendations?)
Date: Sun, 8 Dec 2002 10:22:38 +1000
User-Agent: KMail/1.4.3
References: <5.1.0.14.2.20021207205720.00bb06f8@mail.sutic.nu>
In-Reply-To: <5.1.0.14.2.20021207205720.00bb06f8@mail.sutic.nu>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200212081022.38676.adammurdoch@apache.org>


Several more problems with the narrowing approach:

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

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

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

- Prevents additional services from being added during the lifetime of th=
e=20
component.

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

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 =3D ...;
>
> The two calls:
>
> ((A) proxy).method ();
> ((B) proxy).method ();
>
> are indistiguishable. This is true even if you are using a dynamic prox=
y'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

--=20
Adam

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>