> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> I making the assumption here that the two entities refered to in the
> above paragraph are (a) context type, and (b) context
> entries. While I
> can read on to confirm this, I think we can improve the
> wording so that
> this is clear in the summary.
>
> Here is a suggested replacement of the above paragraph:
>
> The context is the interface through which the component and its
> container communicate. Each Container-Component
> relationship involves
> defining a contract between the two entities. A Context contract is
> defined by (1) an optional target class, and (2) a set of context
> entries. Both parameters may be declared using metainfo.
>
> There are two changes I have made - firstly the explicit
> statement of the two parameters that define the context
> contract, and secondly, stating that this information may be
> declared in metainfo (not metadata).
OK. That seems very sensible. BTW, what's the difference between
metainfo and metadata?
> Here is a revised version of the above:
>
> 1. Context target class or interface
>
> A container shall ensure that a context object supplied
> to a component shall be castable to a target class or
> interface (T). The default target class is Context.
> A
> target class must be derived from or implement the
> Context interface.
This is strictly speaking necessary if T is an interface, and
I see no need to require it. (It is necessary if T is a class,
though.)
>
> Usage:
>
> public void contextualize( Context context )
> throws ContextException
> {
> T tContext = (T) context;
> }
>
>
> >
> > This case has two variants:
> >
> > a. T is an interface. In this case, the container may choose
> > any method to supply the component with a context instance
> > cast-able to T.
> >
> > The container must supply an implementation for all methods
> > in the interface. This may be done via a dynamic proxy
> > that routes calls to appropriate handlers or by any
> > other method. The set of methods that a container must
> > support is defined by the standard context interfaces in
> > Framework (currently none).
> >
> > b. T is a class. In this case, the class must be instantiated
> > with the T(Map,Context) constructor, and the instance
> > then be passed to the component's contextualize method.
> >
> > WARNING: A component that specifies this requirement will not
> > be as portable as one that doesn't. Few containers
> > support it. It is therefore discouraged for components
> > to require a castable context.
> >
>
> I think all of the text related to the "two variants" should
> be removed.
> Point (a) is simply saying that this is a container
> implemetation issue
> and that the object must respect the interface. Both of these are
> implicit if (a) is removed.
I'd like to avoid the implicit stuff, and make it very clear that
it is an implementation issue.
> Point (b) is convention that can be used by
> a container to create a context implementation - it has nothing
> to do with the T parameter as far as the context interface
> is concerned.
As I understood it, T is a class supplied by the component (client),
which means that we must have a contract for its creation and handling
by the container. Or do you propose that we require component
authors to provide one T for each container?
> > <entry intent="avalon:work" type="java.io.File"/>
> >
> > <entry key="work" intent="avalon:work" type="java.io.File"/>
> >
>
> No too happy with the example XML. For me "intent" does not
> convey the semntics here. I would suggest "alias". Secondly,
> I think the example should use full URN naming convensions.
I don't think we have consensus on those. I'd rather leave that for
another proposal.
> Thirdly, the example shows a entry without a key which does not
> compute from my understanding of the example.
>
> Here is suggested replacement:
>
>
> <entry key="urn:avalon:work" type="java.io.File"/>
>
> <entry key="work" alias="urn:avalon:work" type="java.io.File"/>
Hmmm... I'd expect alias to work the other way around:
<entry key="urn:avalon:work" alias="work" type="java.io.File"/>
Since we are aliasing the global key (urn:avalon:work) into a local
namespace with the alias "work".
> > NOTE: The proposal does not cover the DTD, nor does it require
> > that the entries are defined in XML. However, it does
> > require that the above three things *can* be specified.
>
> I think we are so close to being able to close the defintion of
> <context/> that it would be worth doing this as part of the
> proposal.
If we are so close to consensus, then, since that is fairly
orthogonal to this, there should be no problem in breaking
it out to a separate proposal. I'd rather we get what we *do*
have consensus on *now* into the contracts instead of going
another two weeks discussing DTDs. One step at a time.
> The two thing not addressed in the above. One is the "optional"
> attribute that is available in both the meta and info
> packages,
That one was left for later. I did ask for opinions on whether to
include it in my previous draft, but received no response. In the
interest of keeping this proposal minimal, I cut it out.
> and the
> second is semantics that can be applied to the "type" attibute
> value concerning interface/class version.
Left for later.
> >
> > The current list of canonical keys are (taken from
> > http://jakarta.apache.org/avalon/excalibur/info/context.html):
> >
>
> This needs to be normalized with the context keys defined under:
>
> http://jakarta.apache.org/avalon/excalibur/container/attributes.html
>
> >
> > component.name java.lang.String
> > This entry defines the name of the component.
> >
>
> Suggestion:
I cut everything here out. Since we don't have consensus on the
key names, I don't want what we do have consensus on to be stalled
on it.
> > The values placed in the context are runtime values that
> > can only be provided by the container. The Context should
> > NOT be used to retrieve configuration values or services
> > that can be provided by peer components.
>
> I think the last sentense should be removed. If a container
> provides a classloader that is a full component - its in
> conflict with the notion that a standard avalon context entry
> included classloader. I do not think we should be introducing
> statements that are implemetation concerns. If I supply a context
> entry value that meets the entry contract, the client should not
> know or be concerned about the mechansisms used to construct that
> value. The "configuration values" and "services provided by peers"
> are mechanisms - and that's orthoginal to the contract.
The purpose of the sentence is a guideline for accepting future
canonical key names. That is, if person A thinks that it would
be a great idea to have the key urn:avalon:storemanager map to a
org.apache.avalon.StoreService, then we can motivate why that isn't
a good idea by pointing at the sentence above.
How about:
In regards to future canonical key names, it is the intent
that the values placed in the context are runtime values that
can only be provided by the container. The Context should
not be used to retrieve configuration values or services
that can be provided by peer components.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
