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/14 12:03:01 UTC
[Avalon4:VOTE] Context Consensus
Vote remains open to Tuesday, 1200 CET.
-oOo-
PROPOSAL PART 1/2
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 (1) an optional target class, and (2) a set
of context entries.
1. The optional target class is an interface, 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;
}
The container may choose any method to supply the component
with a context instance cast-able to T.
There is no requirement for T to extend the Context interface.
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 part of the context contract defines the set
of entries the component can access via the Context.get()
method, where an entry consists of the key passed to get()
and the expected return type (the class or interface).
Optionally, an alias for the key name can be specified. The
contract associated with a particular entry is defined in the
container documentation.
The class/interface T above may also have associated meta-info
that specifies entries, in which case these entries must be
supplied by the container in addition to any entries the
component itself requires.
See: <a href="package-summary.html#meta">Context Meta-Info
Specification</a>
Standard Avalon context entries, their keys, types and and
associated semantics are defined under the framework standard
attributes table.
See: <a href="package-summary.html#attributes">
Avalon Standard Context Entries Specification</a>
Examples, where the data is specified in a sample XML format:
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.
Example 1: Specification of Canonical Key
When a component specifies:
<entry key="avalon:work" type="java.io.File"/>
It should be able to do:
File workDirectory = (File) context.get( "avalon:work" );
in order to obtain the value.
Example 2: Specification of Canonical Key With Aliasing
When a component specifies:
<entry alias="work" key="avalon:work" type="java.io.File"/>
It should be able to do:
File workDirectory = (File) context.get( "work" );
-oOo-
PROPOSAL PART 2/2
The following text should (after being HTML-ized) be added to the
package summary for org.apache.avalon.framework.context:
<a name="meta"/>
Meta Specification
------------------
Specification of meta-information related to context and
context entries is currently under discussion.
<a name="attributes"/>
Standard Context Entries Specification
--------------------------------------
Specification of standard attribute entries related to context
is currently under discussion.
-oOo-
Here's my +1.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE] Context Consensus
Posted by Stephen McConnell <mc...@apache.org>.
+1
Leo Sutic wrote:
> Vote remains open to Tuesday, 1200 CET.
>
> -oOo-
>
> PROPOSAL PART 1/2
>
> 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 (1) an optional target class, and (2) a set
> of context entries.
>
> 1. The optional target class is an interface, 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;
> }
>
> The container may choose any method to supply the component
> with a context instance cast-able to T.
>
> There is no requirement for T to extend the Context interface.
>
> 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 part of the context contract defines the set
> of entries the component can access via the Context.get()
> method, where an entry consists of the key passed to get()
> and the expected return type (the class or interface).
> Optionally, an alias for the key name can be specified. The
> contract associated with a particular entry is defined in the
> container documentation.
>
> The class/interface T above may also have associated meta-info
> that specifies entries, in which case these entries must be
> supplied by the container in addition to any entries the
> component itself requires.
>
> See: <a href="package-summary.html#meta">Context Meta-Info
> Specification</a>
>
> Standard Avalon context entries, their keys, types and and
> associated semantics are defined under the framework standard
> attributes table.
>
> See: <a href="package-summary.html#attributes">
> Avalon Standard Context Entries Specification</a>
>
> Examples, where the data is specified in a sample XML format:
>
> 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.
>
> Example 1: Specification of Canonical Key
>
> When a component specifies:
>
> <entry key="avalon:work" type="java.io.File"/>
>
> It should be able to do:
>
> File workDirectory = (File) context.get( "avalon:work" );
>
> in order to obtain the value.
>
>
> Example 2: Specification of Canonical Key With Aliasing
>
> When a component specifies:
>
> <entry alias="work" key="avalon:work" type="java.io.File"/>
>
> It should be able to do:
>
> File workDirectory = (File) context.get( "work" );
>
> -oOo-
>
> PROPOSAL PART 2/2
>
> The following text should (after being HTML-ized) be added to the
> package summary for org.apache.avalon.framework.context:
>
> <a name="meta"/>
> Meta Specification
> ------------------
> Specification of meta-information related to context and
> context entries is currently under discussion.
>
> <a name="attributes"/>
> Standard Context Entries Specification
> --------------------------------------
> Specification of standard attribute entries related to context
> is currently under discussion.
>
> -oOo-
>
> Here's my +1.
>
> /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:VOTE] Context Consensus
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
> Vote remains open to Tuesday, 1200 CET.
>
> -oOo-
>
> PROPOSAL PART 1/2
+1
> PROPOSAL PART 2/2
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:VOTE] Context Consensus
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>
> It is not the warning I am worried about. It is use of the
> word 'few'. It is not correct..
Phoenix and EOB have their own derived contexts. But neither
of them supports creation of derived contexts via (for example)
dynamic proxies. Neither does ECM, Fortress and Merlin (although
Merlin does support the instantiation of a context impl).
So I still think "few" is correct, because the support for
other derived contexts than the container's native one
(BlockContext for Phoenix, for example) *is* pretty poor at
the moment.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE] Context Consensus
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo
>>If this is a phrase for the future (when Phoenix has been
>>replaced by UberContainer),
>>
>>
>
>*No.*
>
>[..] thus
>a warning based on the current state of Avalon is valid.
>
>
It is not the warning I am worried about. It is use of the word 'few'.
It is not correct..
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:VOTE] Context Consensus
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>
> > 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.
> If this is a phrase for the future (when Phoenix has been
> replaced by UberContainer),
*No.*
The Über is a big unknown at the moment. Will it be A4 compliant?
Will it be so via a compatibility layer? Will it have A5 features?
What will those be? And so on... Once the Über has been created,
and we have nailed down the different profiles (if any), I expect
this contract to change. But that's a bit in the future, thus
a warning based on the current state of Avalon is valid.
If the Über *does* have very good support for castable contexts,
or if we get such features in many containers, we can just remove the
warning. If not, we let it remain.
> Otherwise +1
Noted your +1. I hope I answered your question and that you are
satisfied with the reply.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE] Context Consensus
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
> 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.
Few? Hmm. Both Phoenix and EOB have their own derived context.
If this is a phrase for the future (when Phoenix has been replaced by
UberContainer), then it might be better to state there there is some
future intent for this.
>
> Here's my +1.
Otherwise +1
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE-RESULT] Context Consensus
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
> Summary:
>
> +1: Leo Sutic
> Leo Simons
> Paul Hammant
> Stephen McConnell
> Nicola Ken Barozzi
>
> +0: (none)
> -0: (none)
> -1: (none)
>
> Proposal passes.
Could you please add this to the resolutions in our STATUS file?
I do this: add the votes to the section where the resolutions are still
b eing voted, commit it for history, then move it without the vote count
under the resolutions.
Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon4:VOTE-RESULT] Context Consensus
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, I have committed the changes.
Some last-minute reformatting was done:
1. I moved the initial note down one sentence. Having a "Note: ..."
as the short description of the Context interface seemed bad.
2. I eliminated the note that said: "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." as it referred to the proposal, and because
the contact states "sample XML format" and we have a note that
we're still working on the meta model.
I'll bring these things up in the post-vote roundup.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Avalon4:VOTE-RESULT] Context Consensus
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Summary:
+1: Leo Sutic
Leo Simons
Paul Hammant
Stephen McConnell
Nicola Ken Barozzi
+0: (none)
-0: (none)
-1: (none)
Proposal passes.
/LS
Note: I haven't forgotten the "after the vote" things.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE] Context Consensus
Posted by Paul Hammant <pa...@yahoo.com>.
> and thanks for the way you're handling this stuff. Very commendable!
Ditto. A difficult duty. You've expertly navigated between the different factions.
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon4:VOTE] Context Consensus
Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-12-14 at 12:03, Leo Sutic wrote:
> Vote remains open to Tuesday, 1200 CET.
>
> -oOo-
>
> PROPOSAL PART 1/2
+1
> PROPOSAL PART 2/2
+1
and thanks for the way you're handling this stuff. Very commendable!
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>