avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: BlockContext & Merlin.
Date Sat, 24 Aug 2002 17:45:16 GMT


Paul Hammant wrote:

> Folks,
>
>    
> http://jakarta.apache.org/avalon/phoenix/api/org/apache/avalon/phoenix/BlockContext.html

>
>
> It appears that Merlin has a problem with mounting blocks.  The 
> problem principally is that though a Context interface is handed in, 
> blocks are in the habit of casting them to BlockContext.  Apart from 
> making all Avalon-Framework using containers need different 
> specializations of Context, it causes Merlin problems with hosting 
> blocks.
>
> This has been discussed over the past year or so, but perhaps now 
> there is need for a solution.  So lets mull over some ideas, and find 
> one that is workable and that everying is happy with.
>
> 1) Merlin includes phoenix-client.jar and provides alternate 
> implemetations of the BlockContext interface.
>
>  (variations are - make phoenix-client.jar smaller by splitting
>   out stuff specific to the Phoenix kernel). 


This is what I'm basically doing at the moment - the Phonix client in 
the excalibur/assembly/lib is a the regular phix-client.jar plus the 
GenericBlockContext implememtation.  I don't like the solution but it 
works in terms of the work I'm doing with James and Cornerstone components.

>
>
> 2) Change cornerstone comps to use Context as is, and access things 
> via 'Object get(Object)'


A more concrete solution would be for the establishment of a common 
attribute for the working directory context key.
In the documentation under the excalibur/container project there is a 
page proposing a set of common context keys and meta info attributes. 
 Phoenix currently provides the "apps.home" key - if this were expanded 
to include the same value under the "avalon:home" key then we would have 
a good solution for undating Cornerstone with minimal impact on Phoenix.

>
>  
> http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/context/Context.html

>
>
> 3) Create a new interface in A-F called say DirectoryNamedContext.  


I think it would be more appropriate to include such an interface under 
the excalibur/container package.  This is where all of the common 
content between Merlin and Fortress resides.

> It has the two methods in BlockContext and extends Context.  
> BlockContext extends it.  Cornerstone comps drop to 
> DirectoryNamedContext.  Merlin is able to trade without reference to 
> Phoenix.  Adding an interface in this way, as we all know is a 
> backwards compatible thing.
>
> Thoughts? ( Concise please ) 


(a) To avoid multiple micro-forks of phoenix-client, it would be 
preferable that a generic block context solution be provided under the 
Phoinix CVS.  This deals with the issue of managing existing non-Avalon 
CVS block implementations that reference BlockContext.

(b) Usage of a common context key such as "avalon:home" resolves 
immediate concerns at the Cornerstone level and provides a model for 
consitency between Phoenix and Merlin.

(c) Defintion of a common context interface for access to a directory 
would make sense within the context of the excalibur/container package. 
I dont think this  sort of thing should go into framework before a more 
comlete container spec/utility-package is in place.

Cheers, Steve.

>
>
> Regards,
>
> - Paul
>
>
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message