Leo Sutic wrote:
Meta info typically declares crieria about a component whereas metadata is used to describe directives. For example, in Merlin the component declares the context crieria in a .xinfo file.
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]OK. That seems very sensible. BTW, what's the difference between
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).
metainfo and metadata?
<type>
<info>
<name>demo</name>
</info>
<context type="org.apache.avalon.phoneix.BlockContext"/>
</type>
This does not specify anything releted to the creation of an instance of BlockContext.
In the specification of a container, the assembler can include metadata that defines the values of things. For example, the following metadata could be used to address the criteria of the above component:
<container>
<component class="MyComponent" name="demo">
<context class="GenericBlockContext"/>
</component>
</container>
This information tells Merlin to use the implentation class GenericBlockContext to construct the context object for the component. Merlin will validate this component profile to make sure it is consistent with the criteria declared by the compoennt mete info.
Following on from you last email - I think we are OK with the type attribute "must be an interface" and that its ok to drop the "derived from Context" clause.
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.)
Coinsidering that the type attribute moves to an interface, then (b) is out of the picture. Point (a) then becomes the generic statement:
Usage:I'd like to avoid the implicit stuff, and make it very clear that
public void contextualize( Context context ) throws ContextException {
T tContext = (T) context;
}
This case has two variants: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.
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.
it is an implementation issue.
It is an implementation detail of a container as to
how it will supply a context instance castable to T.
It 's a seperate subject.
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?
With resolution of a stronger context contract, theree is the totally different subject of implemetation strategies that a container can use to create the context object. The Merlin strategy that your thinking about is just one of mutliple implemetation approaches. Som of the stuff I'm working on at the moment is to define a better context management strategy - but this is on the container side of the problem - i.e. container strategies to fulfill the context criteria.
I don't think we have consensus on those. I'd rather leave that for<entry 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.
<entry key="work" intent="avalon:work" type="java.io.File"/>
another proposal.
Then lets drop the examples.
Thirdly, the example shows a entry without a key which does notHmmm... I'd expect alias to work the other way around:
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"/>
I started to figure that out.
<entry key="urn:avalon:work" alias="work" type="java.io.File"/>With a clean seperation of context meta-info from meta-data, you should not see anything in the meta-info context criteria that states how a context value is created. In the case of the "intent" keyword, I figured you were addressing the issue of a component that iintnds to lookup a context entry using a key that is different from the context entry defined by the context inerface,
Since we are aliasing the global key (urn:avalon:work) into a local
namespace with the alias "work".
For example:
<context type="org.apache.avalon.phoenix.BlockContext">
<entry key="app-name" alsia="urn:avalon:name"/>
<content>
In other words, the alias is the mapping of a context entry defined in the BlockContext defintion named "urn:avalon:name"to the value"app-name".
Anything else would be implemetation instructions which is meta-data which should not present at this level.
If we are so close to consensus, then, since that is fairlyNOTE: 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.
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.
OK.
If we drop the example XML and addrress this subsequently then there isn't a problem.
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.
OK
I cut everything here out. Since we don't have consensus on theThe current list of canonical keys are (taken fromThis needs to be normalized with the context keys defined under:
http://jakarta.apache.org/avalon/excalibur/info/context.html):
http://jakarta.apache.org/avalon/excalibur/container/attributes.html
component.name java.lang.String This entry defines the name of the component.Suggestion:
key names, I don't want what we do have consensus on to be stalled
on it.
That's fine. I think this can be and should be addressed seperately.
I recognize your concern, but I think it is problamatic.
The purpose of the sentence is a guideline for accepting futureThe 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.
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.
I have cases where I'm constructing components that end up in context. Its does not happen very often but the important thing is that the notion of where something comes from and its a service or soomethign else is orthoginal to the context contract. I still think it should dropped. The distinction between context and service is complicated by the fact that existing meta-info mixes the notions of structural creation with usage in the lifecycle. Contextualizable is an aspect of lifecycle - its not a defintion of what sort of thing should or should not appear in context - that's a decision for the developer to take.
Cheers, Steve.
/LS
--
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]>
