avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Locators
Date Sun, 08 Dec 2002 13:16:36 GMT


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 <service> 
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,
>
>     <context>
>         <locator type="org.a.a.f.context.SystemLocator" version="4.1.2"/>
>         <locator type="org.a.j.MailetLocator" version="2"/>
>     </context>
>
> 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:
>
>     <context>
>         <locator type="MyLocator" version="4"/>
>     </context>
>
> 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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message