Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 34343 invoked from network); 8 Dec 2002 13:15:31 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Dec 2002 13:15:31 -0000 Received: (qmail 24527 invoked by uid 97); 8 Dec 2002 13:16:35 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 24480 invoked by uid 97); 8 Dec 2002 13:16:34 -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 24468 invoked by uid 98); 8 Dec 2002 13:16:33 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DF34634.3080807@apache.org> Date: Sun, 08 Dec 2002 14:16:36 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Locators References: <5.1.0.14.2.20021208121119.00bd05d8@mail.sutic.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leo Sutic wrote: > Stephen, > > OK, now I get it. I thought that the lookup operation would be > replaced by casting, so that if I had a component that had a > dependency on, say, StoreService and ConnectionPool, I would do this: > > public void service (Locator locator) { > StoreService ss = (StoreService) locator; > ConnectionPool cp = (ConnectionPool) locator; > } > > That was the root of my "but method names will conflict" post. Ok, understand. The casting I was refering to was the "type of locator" - which simply brings your to a sugar-coated locator. The inclusion of the element only provides a keyed entry - it did not (or was not intended to imply) casting to a service interface. But looking back at my email - that wasn't so clear! > > I think your proposal and mine are very similar. That's may impression as well. > > We both allow the component to declare a context with any key-value > mappings, and you extend it to allow even services to be accessed via > a context. Where you have the component cast the context interface to > multiple locator interfaces: > > That is, > > > > > > > means that: > > public void contextualize( Locator locator ) throws > LocatorException { > SystemLocator system = (SystemLocator) locator; > MailetLocator mailet = (MailetLocator) locator; > } > > is valid. > > I would aggregate the two interfaces like this: > > interface MyLocator extends SystemLocator, MailetLocator {} Me too. However, keep in mind that the meta model should support this. In other words, a locator service meta (as distinct from a locator implementation meta) should be declaring the keys it provides, and the super type service meta is is derived from. Given that - it will be possible to establish key conflicts during build time. > > declare it like this: > > > > > > and then do this: > > public void contextualize( Locator locator ) throws > LocatorException { > MyLocator myLocator = (MyLocator) locator; > } > > Is the above a correct understanding of your Locators? Yep. I'm also thinking that it is reasonable to break out the single locator verus locator aggregation. If locator service interfaces use inheritance and that inheritance is backed be equivalent meta, then, in the first instance I don't think we need to worry about delivering aggregation of multiple locator instances just yet. The key thing is the delivery of the ability of component writters to write their own locators and have these as a standard mechanisms across different containers. In effect, the locator becomes an important part of the container-side customization of a system. Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: