Noel J. Bergman wrote:
Nope.Just a note - IS-A can define the HAS-A contact (providing meta isThe issue is that IS-A is an inherently coupled relationship. As a TYPE,
provided against the IS-A interface declaring the set of entries).
you do not want to cast contexts. You do not want to couple the client code
with any inherited implementation.
I'm convergin on the same opinion - one locator is sufficient.That will please me greatly, especially if the Community follows suit.
I do assume from the context of our other discussions that you mean one
object exposed to the client. Possibly multiple internal "sub-contexts"
that provide the service as required for a given lookup.
<type>
<context locator="o.a.a.p.BlockContext" version="2.1"/>
</type>
How literally am I to take that? You aren't really proposing BlockContext as the actual iterface, are you? I don't expect that you are, but clarification won't hurt.
:-)
I'm applying the same logic that is used to find and deploy lifecycle extension handlers.
The locator attribute tag declares:
(a) that the container has to locate a component exposing
meta that declares itself as a locator (basically a meta
type that extends "Type" with the attition of one or more
interfaces it can be proxied as, and the set of lookup
tags that it supports
and the locator attribute value declares:
(b) that the locator component must provide or implement the
interface class - which the container resolves through
the additional meta information
The container treats the locator as a classic component, assembles and establishes the Locator instance and plugs this in as the source of context or service management requests behind the respective Context or ServiceManager. An actual Context object can be created as a proxy by the container wrapping the Locator instance. In addition, would also be possible to provide a common locate operation on both Context and ServiceManager so that the same samantics can be used for both contextualize and service (and in a way that does not break backward compatibility).
This means that something like BlockContext can be implememntated as a classic component (with depedencies, its own context criteria, configuration, etc.) and dynamically plugged into a target component.
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]>
