avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Avalon4:PROPOSAL] Context Consensus
Date Wed, 11 Dec 2002 14:03:40 GMT

> From: Leo Simons [mailto:leosimons@apache.org] 
> my previous replies I forgot to send apparently, so here it goes...
> On Wed, 2002-12-11 at 00:23, Leo Sutic wrote:
> > There is currently *not* consensus that a component should be able
> > specify any interface that it should be able to cast the context to.

> > That is, for every class/interface T,
> > 
> >      public void contextualize (Context context) {
> >          T myContext = (T) context;
> >      }
> > 
> > the component should be able to declare that it expects to cast the 
> > context
> > to a T. (For a less abstract example, replace T with BlockContext.)
> note: the main reason I don't like this is because it means 
> the container impl must do proxying, which is heavyweight.

Note that the proposal does *not* say that the container must be able
to *satisfy* any request. It merely acknowledges that a component
may *ask* for a context class T.

You are free to disallow any components asking for a class in your
container, if you think that the implementation of it would be
too heavyweight.

The same goes for the no-active-operations-in-context. The proposal
says that the component may *ask* for such operations, but it also
states that there are no *required* operations that all containers 
must support, meaning that your container can completely disallow
any component requesting such an operation.

The reason both these things are in the proposal is because it is
impossible to capture the Phoenix usage pattern without them - i.e.
you can't describe the requirements of a Phoenix block. Disallowing
active operations at a Framework level would effectively put Phoenix
into non-compliance with Framework, that's why a component must be
able to *ask* for them, but a container must not have to supply them.

Still a problem?

> > 
> > 1. A list of canonical keys and their meaning can be found at:
> > 
> >      http://jakarta.apache.org/avalon/excalibur/info/context.html
> > 
> > Should these be made Framework-wide canonical keys?
> yes.

Noted. (With motivation.)

> > 2. Should the context entries include an "isOptional" attribute:
> > 
> >    <entry intent="avalon:work" type="java.io.File" 
> > is-optional="true"/>
> > 
> >     ?
> I think this is a nice experimental feature that need not be 
> supported in avalon framework 4 till we figure out if it is 
> truly needed and in widespread use. There's other is-<blaat> 
> things one could think of. I suggest keeping it out of the proposal.
Noted. (With motivation.)


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message