Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 94755 invoked from network); 3 Dec 2002 10:35:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Dec 2002 10:35:12 -0000 Received: (qmail 6411 invoked by uid 97); 3 Dec 2002 10:36:26 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 6320 invoked by uid 97); 3 Dec 2002 10:36:25 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 6308 invoked by uid 98); 3 Dec 2002 10:36:25 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon Developers List" Subject: Re: Context: usage recommendations? ( Re: [SUMMARY] Context ) Date: Tue, 3 Dec 2002 21:45:08 +1100 User-Agent: KMail/1.4.2 References: <001401c29a47$0b4b6080$6401a8c0@LEIBNIZ> <200212031642.14510.peter@realityforge.org> <200212032017.59793.adammurdoch@apache.org> In-Reply-To: <200212032017.59793.adammurdoch@apache.org> X-Notice: Duplication and redistribution prohibited without consent of the author. X-Copyright: (C) 2002 Peter Donald. X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200212032145.08387.peter@realityforge.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote: > Sure. These are good examples of why everyone wins when there's a nice > match between what a resource means to a component, and how the resourc= e is > delivered to the component. If the component wants a logger, give it a > logger. If the component wants config, give it config. etc. Maybe th= e > same resource is presented in different ways depending on how the compo= nent > asks for it. Maybe not. Component doesn't care. >=20 > But the examples don't really answer the question: Why is it useful, w= hen > a component asks for a resource of a particular type, to distinguish > between resources of that type that are provided by the container, and > resources of that type that are provided by other components? I don't really understand what you are getting at. If you are wanting to = unify=20 the interface then this has already proposed - I actually created another= =20 service API recently that looked something like interface Composable { void compose( Locator locator ) throws LocatorException; } interface Contextualizable { void contextualizable( Locator locator ) throws LocatorException; } interface Locator { Object lookup( String key ) throws LocatorException; boolean exists( String key ); } If thats what you mean then I think I agree. It resulted in cleaner code. If you mean merging Contextualizable and Composable then I disagree.=20 --=20 Cheers, Peter Donald "The ability to quote is a serviceable substitute for wit." -- Maugham=20 -- To unsubscribe, e-mail: For additional commands, e-mail: