avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Phoenix Beta
Date Mon, 05 Aug 2002 12:24:55 GMT

Hi Paul:

The principal issue I have concerning Phoenix escalation to beta 
concerns (a) the XML schema used to describe blocks, and (b) the 
specification of how blocks are declared.  Currently the Phoenix 
platform uses <blockinfo/> and the existence of blocks is derived from 
the assembly/configuration info.  In the past, block existence was 
declared in the manifest files containing the block implementation - 
however this does not seem to be the case anymore.  I believe Pete is 
also in the process of adding support for the containerkit schema.

At the same time we have components using the Merlin model which 
includes additional meta-info dealing with (a) lifecycle phase 
dependencies, (b) lifecycle extension handler provision, and (c) a type 
specific default configuration.  Merlin provides support for both the 
"containerkit" DTD and the Merlin "type" DTD so loading containerkit 
(Phoenix) based components into Merlin will not be a problem.  However, 
the absence of manifest based declaration of the components within a jar 
file is problematic.  Merlin uses this information to establish 
potential component service provider candidates whereas Phoenix assumes 
that the everything is declared in the assembly.xml file.

Assuming that the containerkit schema is included in Phoenix, then, the 
only issue concerning interoperability of phoenix style components in 
Merlin is the resolution of the Manifest question.

We could also go a step further and replace the containerkit meta-info 
model for the excalibur.meta meta-info model.  This would ensure an even 
higher level of interoperability and its very simple to do - all it 
implies is that the (a) containerkit meta info uses excalibur.meta 
instead of the current containerkit.info package (which is really easy 
because excalibur.meta is already packaged as a separate extension jar 
file), and (b) Phoenix would need to check for things it cannot support 
(e.g. lifecycle extensions implied by phase, extension elements), and 
(c) manage or throw out types that declare default configurations.


Cheers, Steve.


Paul Hammant wrote:

> Folks,
>
> Can we debate a feature cap for a beta release please?  Last time this 
> was raised, we were talking of imminent JMX work being the 
> blocker..... has that now been achieved?
>
> - Paul
>
>
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-phoenix-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-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message