avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [ANTI-VOTE] Lifecycle Extension Tags
Date Tue, 29 Jul 2003 00:18:47 GMT


Leo Sutic wrote:

>  
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>
>>In this case, Phoenix would be able to recognize the 
>>components as requiring functionality it can't deliver, and 
>>then refuse to deploy it.  This addresses both Stephen's and 
>>my concerns.
>>    
>>
>
>Wait wait wait wait wait...
>
>If a tag has to be explicitely recognized by all containers, i.e.
>the container must do this:
>
>    if (tag.equals ("lifecycle")) {
>        fail ("I don't support that tag.");
>    }
>
>instead of just defaulting:
>
>    if (!supportedTags.contains (tag)) {
>        fail ("I don't support that tag.");
>    }
>
>Then it should be in the avalon namespace.
>

Exactly.

>
>Why? Well, in the first case, a container must test for the
>tag whether or not it supports it. In the second 
>case you just get a "sorry, can't do that".
>
>So what is the score with Phoenix now? Does Phoenix
>read any tags? If yes, what will it do with a component that
>has a lifecycle tag?
>  
>

Most of the Phoneix apps I've worked with are using hand coded 
<blockinfo/> descriptors.  But there are user (e.g. James community) 
that are processing these using the Phoenix 
org.apache.avalon.phoenix.framework.tools.ant.MetaGenerateTask class.  
It would be a trivial exercise to update this tool to handle stage 
declarations awareness. I.e. if a stage  is declared then throw an error 
and fail the generation of the descriptor.  Same case for context 
casting other than BlockContext or context entry criteria that is 
outside of the Phoenix suite.

Also (and this many not be perfectly accurate) that the <blockinfo> 
descriptor in Phoenix is considered as legacy and the containerkit model 
is used internally.  I have no idea if Phoenix actually reads anything 
other than blockinfo - but at least there is an internal model that is 
consistent with the avalon-meta project.

Steve.


>/LS
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message