Noel J. Bergman wrote:
Just a note - IS-A can define the HAS-A contact (providing meta is provided against the IS-A interface declaring the set of entries).The casting I was refering to was the "type of locator"Why do we need more than one TYPE (interface)? Define a consistent, uniform, SINGLE, interface. Aggregate by reference and naming space, as we discussed previously with respect to URNs.I would aggregate the two interfaces like this: interface MyLocator extends SystemLocator, MailetLocator {}Me too.Oiy ... please don't make me do it. Please don't make me explain about IS-A and HAS-A again.
As your reading though this stuff you will see that I'm convergin on the same opinion - one locator is sufficient.A Component should see a single "locator" object that provides access to other objects.
I.e. the current:
<type>
<context type="o.a.a.p.BlockContext">
<entry key="apps.dir" type="java.io.File"/>
<!-- etc. -->
</context>
</type>
Can be replaced by:
<type>
<context locator="o.a.a.p.BlockContext" version="2.1"/>
</type>
The "meta-model" should provide the information necessary to register what is in the context. And there should be APIs for dynamic registation.
Agreed.
IMO, a Context should be a provider of objects within a given, well, "context." Those objects provide data and/or services. Some of those objects are well-defined and provided by the Container profiles. Other objects are defined by third parties, and usable primarily by others expecting those third party entries. The preceeding does not mean that a third party can't replace a profile defined object, given the correct administrative rights.
Yep. Cheers, Steve.
--- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 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]>
