avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Context - a future
Date Mon, 25 Nov 2002 14:31:15 GMT
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
> 
> Can someone who is _not_ advocating any of the competing 
> propositions for Context please lead this
> task:
> 
> We need a 'roll-up' on this rapidly sprawling thread.  Many 
> people (incl me) are being lost in the
> extensive detail.
> 
> 1) What are the competing solutions .. hashmap style get(), 
> cast to Context derived interfaces etc
> ...

Concider the comments from my other post: "On Context".  That
was its purpose.  There will be certain instances where it
is better to have the Container take care of the Context building
and pass it to specific components like this:

Servlet {
    initialize( ServletConfiguration config );
}

ServletConfiguration {
    ServletContext getContext();
}

It could be something like Cocoon would want to pass the ServletContext
like CocoonContext to all its components via the contextualize()
method.  If so, the user would have the option of casting the
context to a CocoonContext object--forever scoping their component
to Cocoon, or using the more generic version of the interface.

There are pros and cons.  Anytime a Context is used, hopefully
there is some sort of "living area" for the set of components
in an application.  That living area can be a directory on the
server, or it can be a work area that all the different components
share.  Those can be constants to the Context object (it would
work for Servlets and Blocks).

It is not an easy thing to say "This is how we do it".


> 2) What is the timescale we are trying aim for?  Can it go 
> into Phoenix and Merlin or is it a
> revolution, thus only for uber-container?

It is a refinement of the Container/Component contracts.

I do not think that we have to preclude the casting of the
generic Context to a more specific context.  I do think we
should have a minimal standard set of values that are always
bound to the Context--things that configurations won't be
able to handle.


> The idea is that we get one summary of the choices.  It may 
> be that me, Stephen, Leo(s) post
> comment and the rollup is modified.  Best to leave the start 
> of this to unaligned person though.

I fail to see what the major issue is?  We need to add warnings
that if the Context is cast to something more specific, you are
effectively limiting your components to a specific container.
Alternatively, we may want to simply pass in a typed context.  In
that case we would need a way to intelligently alter the lifecycle.

That would require Peter's solution to be done and adopted, and
that would be a revolution and slated for Avalon 5.

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


Mime
View raw message