You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/12/12 20:59:06 UTC
[Avalon4:PROPOSAL] Context Consensus (version 2)
All,
I hope I have incorporated all comments. Here's the latest draft
of the proposal. I'd like to go for a vote on this next Tuesday,
and I would appreciate if anyone not satisfied with it could say
so now, so the concerns can be addressed while it is still a
[PROPOSAL] and not a [VOTE]. I know that the proposal as it
stands is less-than-optimal for everyone, but it is my gut
feeling that it is also at least acceptable to everyone, which
is why I'm going forward with it.
-oOo-
Proposal: The following text should (after being HTML-ized) replace
the current documentation for the Context interface:
NOTE: In the text below there are several requirements that a
component may set up for a container. It is understood that
a container does not have to satisfy those requirements in
order to be Avalon-compliant. If a component says "I require
X to run" a container may reply with "I don't have any X, so
I'm not running you". The requirements here are the maximum
that a component may ask for, not the minimum a container must
deliver. However, a container should document what it is and
isn't capable of delivering.
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 two parameters, both of which are requirements the component
set up for the container in its metadata:
1. The first is an interface or a class, called T below. It is
required that the component should be able to perform the
following operation:
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.
2. The second parameter is a set of entries accessible via the
Context.get() method and their types. The class/interface T
above may also have associated metadata that specifies entries,
in which case these entries must be supplied by the container
in addition to any entries the component itself requires.
Each entry requirement must specify the canonical key name, may
specify a name that the canonical key should be remapped to,
and must specify the expected type of the value:
For an example, where the data is specified in XML:
<entry intent="avalon:work" type="java.io.File"/>
<entry key="work" intent="avalon:work" type="java.io.File"/>
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.
The current list of canonical keys are (taken from
http://jakarta.apache.org/avalon/excalibur/info/context.html):
component.name java.lang.String
This entry defines the name of the component.
component.classloader java.lang.ClassLoader
The classloader via which the component was loaded. May differ
from the ClassLoader returned by getClass().getClassLoader() if
the component was loaded from parent classloader.
partition.name java.lang.String
This entry defines the name of the partition.
application.name java.lang.String
This entry defines the name of the application.
component.home java.io.File
The location in which the component to store persistent data
relevent to the component.
component.work java.io.File
This directory in which to store temporary or working
information. It may not persist over restarts of the component.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Peter Donald <pe...@realityforge.org>.
+1
On Fri, 13 Dec 2002 06:59, Leo Sutic wrote:
> All,
>
> I hope I have incorporated all comments. Here's the latest draft
> of the proposal. I'd like to go for a vote on this next Tuesday,
> and I would appreciate if anyone not satisfied with it could say
> so now, so the concerns can be addressed while it is still a
> [PROPOSAL] and not a [VOTE]. I know that the proposal as it
> stands is less-than-optimal for everyone, but it is my gut
> feeling that it is also at least acceptable to everyone, which
> is why I'm going forward with it.
>
> -oOo-
>
> Proposal: The following text should (after being HTML-ized) replace
> the current documentation for the Context interface:
>
> NOTE: In the text below there are several requirements that a
> component may set up for a container. It is understood that
> a container does not have to satisfy those requirements in
> order to be Avalon-compliant. If a component says "I require
> X to run" a container may reply with "I don't have any X, so
> I'm not running you". The requirements here are the maximum
> that a component may ask for, not the minimum a container must
> deliver. However, a container should document what it is and
> isn't capable of delivering.
>
> 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 two parameters, both of which are requirements the component
> set up for the container in its metadata:
>
> 1. The first is an interface or a class, called T below. It is
> required that the component should be able to perform the
> following operation:
>
> 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.
>
> 2. The second parameter is a set of entries accessible via the
> Context.get() method and their types. The class/interface T
> above may also have associated metadata that specifies entries,
> in which case these entries must be supplied by the container
> in addition to any entries the component itself requires.
>
> Each entry requirement must specify the canonical key name, may
> specify a name that the canonical key should be remapped to,
> and must specify the expected type of the value:
>
> For an example, where the data is specified in XML:
>
> <entry intent="avalon:work" type="java.io.File"/>
>
> <entry key="work" intent="avalon:work" type="java.io.File"/>
>
> 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.
>
> The current list of canonical keys are (taken from
> http://jakarta.apache.org/avalon/excalibur/info/context.html):
>
> component.name java.lang.String
> This entry defines the name of the component.
>
> component.classloader java.lang.ClassLoader
> The classloader via which the component was loaded. May differ
> from the ClassLoader returned by getClass().getClassLoader() if
> the component was loaded from parent classloader.
>
> partition.name java.lang.String
> This entry defines the name of the partition.
>
> application.name java.lang.String
> This entry defines the name of the application.
>
> component.home java.io.File
> The location in which the component to store persistent data
> relevent to the component.
>
> component.work java.io.File
> This directory in which to store temporary or working
> information. It may not persist over restarts of the component.
>
> 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
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Thanks, I'll see what I can incorporate in the proposal without
breaking consensus.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Attached is a document I worked up a couple of hours ago containing a
consilidation of this in a non-email document.
Based on the last set of emails - it looks like only the first part if
relevant - but I figured it would be helpful to post anyway.
Chers, Steve.
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Paul Hammant wrote:
>>
>>
>>
>>>I'm unhappy with anything other than a base interface (Context) or
>>>specialised interfaces (e.g. BlockContext)
>>>
>>>
>>I agree
>>
>>
>
>OK, the thing was there to accomodate the current Merlin usage
>pattern.
>
Merlin only uses the type attribue value as a cast criteria. I think
you getting mixed up between meta-info and meta-data - but I'll answer
that one in reply to the other post from yourself.
>If you are both happy with it going, then I'm removing
>it.
>
> T must be an interface.
>
>
+1
>(Although I see no need to require that the interface extends the
>Context interface.)
>
>
OK.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Paul Hammant wrote:
>
> > I'm unhappy with anything other than a base interface (Context) or
> > specialised interfaces (e.g. BlockContext)
>
>
> I agree
OK, the thing was there to accomodate the current Merlin usage
pattern. If you are both happy with it going, then I'm removing
it.
T must be an interface.
(Although I see no need to require that the interface extends the
Context interface.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen, Leo,
>
>> [...] A Context contract is
>> defined by (1) an optional target class,
>> [...]
>> 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.
>
>
> I'm unhappy with anything other than a base interface (Context) or
> specialised interfaces (e.g. BlockContext) being used to descibe
> parameter0 of contextualize for the IS-A proposition. Why? K/HC/CAPI
> separation; separation of interface and impl etc. As an advocate of
> the BlockContext (and alike) solution I have no requirement for things
> like GenericBlockContext (it was a class not an interface).
I agree - it was something that was bugging me about the summary. I
would prefer that the value of "type" on a <context> element be
restricted to an interface derived from Context. Things like
"GenericBlockContext" could appear as part of a creation directive
(meta-data), but that has nothing to do with the context criteria
expressed by a component towards the container and is not relevant to
the Context interface specification.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>
> I'm unhappy with anything other than a base interface (Context) or
> specialised interfaces (e.g. BlockContext) being used to descibe
> parameter0 of contextualize for the IS-A proposition. Why? K/HC/CAPI
> separation; separation of interface and impl etc. As an
> advocate of the
> BlockContext (and alike) solution I have no requirement for
> things like
> GenericBlockContext (it was a class not an interface).
Could you expand your acronym for me, I am not familiar with it:
K/HC/CAPI
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen, Leo,
> [...] A Context contract is
> defined by (1) an optional target class,
> [...]
> 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.
I'm unhappy with anything other than a base interface (Context) or
specialised interfaces (e.g. BlockContext) being used to descibe
parameter0 of contextualize for the IS-A proposition. Why? K/HC/CAPI
separation; separation of interface and impl etc. As an advocate of the
BlockContext (and alike) solution I have no requirement for things like
GenericBlockContext (it was a class not an interface).
Other than that, I was fairly happy with Leo's last rollup.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Entry key names should conform to URN naming
> conventions specificed under RFC 2141 where the format of a
> URN is "urn:" <NID> ":" <NSS>. NID is Namespace IDentifier,
> and NSS is Namspace Specific String. The NID "avalon" is
> reserved for standard Avalon context key entries.
I'd go a bit further: all NID strings beginning with the word avalon are
reserved.
I am in favor of RFC 2141 as normative, but note that as long as the strings
are well formed, multiple naming conventions can be allowed. The urn:
prefix tells us that RFC 2141 is the protocol for that request.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Problem is that it is statating that there is a notion of
> container-provided versus peer-provide - and that something I
> disagree
> with. There has been a lot of disucussion about this and the
> notion of
> "not" declaring where something comes from.
OK, cutting that paragraph.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>> 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 recognize your concern, but I think it is problamatic.
>>
>>I have cases where I'm constructing components that end up in
>>context. Its does not happen very often
>>
>
>That was my intent with the new text - basically saying that
>"this is what we recommend in general, but as always
>there are times when you have to do something else."
>
Problem is that it is statating that there is a notion of
container-provided versus peer-provide - and that something I disagree
with. There has been a lot of disucussion about this and the notion of
"not" declaring where something comes from. A component should not care
how context entries are resolved - and this text is implying that there
are restrictions related to the sort of information your going to get
from context in terms of where it comes from - and I think thats a bad
thing.
>
>Can you think of a better way of saying it, if you agree
>with the sentence above?
>
Given that meta-info and standard attribute names can be shifted to a
subsequent step, the issues your addessing here are:
(a) convenstions concerning entry key naming
(b) conventions concerning context usage
On the subject of (a) I think comes down to being explicit about
recommending the use of RFC 2141and specifically declaraing the "avalon"
NID. On the subject of (b), I don't think there is anything that should
be said. So, if I were to propose something it would look like the
following:
Entry key names should conform to URN naming
conventions specificed under RFC 2141 where the format of a
URN is "urn:" <NID> ":" <NSS>. NID is Namespace IDentifier,
and NSS is Namspace Specific String. The NID "avalon" is
reserved for standard Avalon context key entries.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> > 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 recognize your concern, but I think it is problamatic.
>
> I have cases where I'm constructing components that end up in
> context. Its does not happen very often
That was my intent with the new text - basically saying that
"this is what we recommend in general, but as always
there are times when you have to do something else."
Can you think of a better way of saying it, if you agree
with the sentence above?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>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?
>
>
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.
<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.
>
>
>>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.)
>
>
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.
>
>
>>
>> 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.
>
>
Coinsidering that the type attribute moves to an interface, then (b) is
out of the picture. Point (a) then becomes the generic statement:
It is an implementation detail of a container as to
how it will supply a context instance castable to T.
>
>
>>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?
>
>
It 's a seperate subject.
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.
>
>
>>> <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.
>
>
Then lets drop the examples.
>>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:
>
>
I started to figure that out.
> <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".
>
>
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,
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.
>
>
>
>>> 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.
>
>
OK.
>
>
>> 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.
>
>
If we drop the example XML and addrress this subsequently then there
isn't a problem.
>
>
>>and the
>>second is semantics that can be applied to the "type" attibute
>>value concerning interface/class version.
>>
>>
>
>Left for later.
>
>
OK
>
>
>>> 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.
>
>
That's fine.
I think this can be and should be addressed seperately.
>
>
>>> 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.
>
I recognize your concern, but I think it is problamatic.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>All,
>
>I hope I have incorporated all comments. Here's the latest draft
>of the proposal. I'd like to go for a vote on this next Tuesday,
>and I would appreciate if anyone not satisfied with it could say
>so now, so the concerns can be addressed while it is still a
>[PROPOSAL] and not a [VOTE]. I know that the proposal as it
>stands is less-than-optimal for everyone, but it is my gut
>feeling that it is also at least acceptable to everyone, which
>is why I'm going forward with it.
>
Leo:
More notes in-line.
>
> -oOo-
>
>Proposal: The following text should (after being HTML-ized) replace
>the current documentation for the Context interface:
>
>NOTE: In the text below there are several requirements that a
> component may set up for a container. It is understood that
> a container does not have to satisfy those requirements in
> order to be Avalon-compliant. If a component says "I require
> X to run" a container may reply with "I don't have any X, so
> I'm not running you". The requirements here are the maximum
> that a component may ask for, not the minimum a container must
> deliver. However, a container should document what it is and
> isn't capable of delivering.
>
>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 two parameters, both of which are requirements the component
>set up for the container in its metadata:
>
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).
>
>1. The first is an interface or a class, called T below. It is
> required that the component should be able to perform the
> following operation:
>
> public void contextualize( Context context )
> throws ContextException
> {
> T tContext = (T) context;
> }
>
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.
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. 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.
Secondly, it mixes the notion of T as a cast criteria with the notion
of T as a directive for context creation. T as a criteria is
appropriate within the scope of metainfo. T as a directive is
appropriate within the scope of metadata. I don't think we should
documeting directive under Context interface specification as directives
are related to implemetation, not contract. However, I do think we can
provide a link to this sort of information - for example, it would be
appropriate to include this under the DefaultContext implementation spec
or as part of a metadata for context specification included in the
context package documentation.
>
>2. The second parameter is a set of entries accessible via the
> Context.get() method and their types. The class/interface T
> above may also have associated metadata that specifies entries,
> in which case these entries must be supplied by the container
> in addition to any entries the component itself requires.
>
> Each entry requirement must specify the canonical key name, may
> specify a name that the canonical key should be remapped to,
> and must specify the expected type of the value:
>
> For an example, where the data is specified in XML:
>
> <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. 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"/>
>
> 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.
The two thing not addressed in the above. One is the "optional"
attribute that is available in both the meta and info packages, and the
second is semantics that can be applied to the "type" attibute value
concerning interface/class version.
E.g.:
<entry key="urn:avalon:classloader" type="ComponentClassLoader:1.2"/>
Doing a DTD for <context/> allows us to be precise about the meaning of "type", "alias", "key", and "optional".
>
> 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:
urn:avalon:name
>
> component.classloader java.lang.ClassLoader
> The classloader via which the component was loaded. May differ
> from the ClassLoader returned by getClass().getClassLoader() if
> the component was loaded from parent classloader.
>
Suggestion:
urn:avalon:classloader
>
> partition.name java.lang.String
> This entry defines the name of the partition.
>
Suggestion:
urn:avalon:partition.name
>
> application.name java.lang.String
> This entry defines the name of the application.
>
Suggestion:
urn:avalon:application.name
>
> component.home java.io.File
> The location in which the component to store persistent data
> relevent to the component.
>
Suggestion:
urn:avalon:home
or:
urn:avalon:home.directory
>
>
> component.work java.io.File
> This directory in which to store temporary or working
> information. It may not persist over restarts of the component.
>
Suggestion:
urn:avalon:work
or:
urn:avalon:work.directory
>
> 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.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Gary Shea [mailto:shea@gtsdesign.com]
>
> I'd prefer to see keys that are as self-documenting as
> possible, just in case someone has to interpret their
> intention in string form. How about
>
> component.home.directory
> component.working.directory
>
> Lets not go back to the old C days...
Worse, there is little consensus on what the keys should be.
URNs, etc. I'm leaning toward just cutting that part out
and leaving it for later.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:PROPOSAL] Context Consensus (version 2)
Posted by Gary Shea <sh...@gtsdesign.com>.
One comment down near the bottom...
On Thu, 12 Dec 2002, at 20:59 [+0100], Leo Sutic (leo.sutic@inspireinfrastr...:
> All,
>
> I hope I have incorporated all comments. Here's the latest draft
> of the proposal. I'd like to go for a vote on this next Tuesday,
> and I would appreciate if anyone not satisfied with it could say
> so now, so the concerns can be addressed while it is still a
> [PROPOSAL] and not a [VOTE]. I know that the proposal as it
> stands is less-than-optimal for everyone, but it is my gut
> feeling that it is also at least acceptable to everyone, which
> is why I'm going forward with it.
>
> -oOo-
>
> Proposal: The following text should (after being HTML-ized) replace
> the current documentation for the Context interface:
>
> NOTE: In the text below there are several requirements that a
> component may set up for a container. It is understood that
> a container does not have to satisfy those requirements in
> order to be Avalon-compliant. If a component says "I require
> X to run" a container may reply with "I don't have any X, so
> I'm not running you". The requirements here are the maximum
> that a component may ask for, not the minimum a container must
> deliver. However, a container should document what it is and
> isn't capable of delivering.
>
> 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 two parameters, both of which are requirements the component
> set up for the container in its metadata:
>
> 1. The first is an interface or a class, called T below. It is
> required that the component should be able to perform the
> following operation:
>
> 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.
>
> 2. The second parameter is a set of entries accessible via the
> Context.get() method and their types. The class/interface T
> above may also have associated metadata that specifies entries,
> in which case these entries must be supplied by the container
> in addition to any entries the component itself requires.
>
> Each entry requirement must specify the canonical key name, may
> specify a name that the canonical key should be remapped to,
> and must specify the expected type of the value:
>
> For an example, where the data is specified in XML:
>
> <entry intent="avalon:work" type="java.io.File"/>
>
> <entry key="work" intent="avalon:work" type="java.io.File"/>
>
> 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.
>
> The current list of canonical keys are (taken from
> http://jakarta.apache.org/avalon/excalibur/info/context.html):
>
> component.name java.lang.String
> This entry defines the name of the component.
>
> component.classloader java.lang.ClassLoader
> The classloader via which the component was loaded. May differ
> from the ClassLoader returned by getClass().getClassLoader() if
> the component was loaded from parent classloader.
>
> partition.name java.lang.String
> This entry defines the name of the partition.
>
> application.name java.lang.String
> This entry defines the name of the application.
>
> component.home java.io.File
> The location in which the component to store persistent data
> relevent to the component.
>
> component.work java.io.File
> This directory in which to store temporary or working
> information. It may not persist over restarts of the component.
I'd prefer to see keys that are as self-documenting as possible, just in
case someone has to interpret their intention in string form. How about
component.home.directory
component.working.directory
Lets not go back to the old C days...
Gary
>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>