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

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