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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
