avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces ApplicationContext.java Kernel.java
Date Sat, 07 Sep 2002 17:32:44 GMT

Nicola Ken Barozzi wrote:

> - Now it seems to me that BlockContext would be an excellent candidate 
> for the containerkit Context.
> I would humbly propose to maybe put the BlockContext in containerkit, 
> deprecate the one in Phoenix, make the Phoenix one extend the 
> containerkit one for compatibility, and make Cornestone blocks, which 
> IIUC Peter also would like to see a components in excalibur (or 
> something like that), use the containerkit context.
> What do you think, is it viable?

 We have Context interface and that is completely workable.  With the 
two meta-info models that exist (excalibur/meta and excalibur/info) you 
the ability to declare that a component has a requirement for the supply 
of a context object such that it can be narrowed to some other 
interface.  However, you alway have the constraint that we are talking 
about a Context derivative.  Context works well if you respect its 
purpose and function.  Introducing something like BlockContext into 
either the meta or info packages does not make sence because that are 
about describing something like a BlockContext.  Introducing 
BlockContext into excalibur/container would make sence if there is 
agreement across at least a couple of container projects.  Introducing 
BlockContext into containerkit is equivalent to leaving it where it is 

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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