avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: merlin meta-tool
Date Wed, 14 May 2003 02:05:31 GMT

kristian meier wrote:

> Hi,
> I played around with the meta-generator task. one question was why it 
> generates .xtype files ? I always use .xinfo for merlin. 

The .xtype file extension explicitly deals with the potential for a 
component type to be deployed within Phoenix and Merlin (e.g. James).  
Phoenix expects to find a xinfo file containing a root <blockinfo> 
element and if Phoenix were presented with a root <type> element it 
would fail.  Merlin checks for a .xtype and if not found, it checks for 
xinfo - if a xinfo exists, Merlin will load it in accordance with the 
root element (either <type> or <blockinfo>).

> there is the common case where I just extends AbstractLogEnabled and 
> don't  overwrite the enableLogging method. in
> this case I can not create a new logger channel. somehow I wish to 
> define it in the class-scope instead of the method-scope.

The logging channel declaration only concerns sub-categories relative to 
the root logging cattegory that will be supplied to the component.  
Merlin establishes the requirement for a logger based on the classes 
implementation of the LogEnabled interface.  Addition category 
declarations are only needed if your component wants to declare its 
usage of logging sub-categories.  In such a case you would would 
normally override the enableLogging operation. 

I agree that this is not strictly needed - as such there is an argument 
for placing logging criteria at the class level - providing we add a 
check that the component class does in fact implement the log enabled 
interface somewhere in its inheritance graph.

> similiar things hold for the service method, furthermore the tags 
> should be examine going down the class-hierachy. 

In respect to the first part of the question (re. similar things on 
logging and service) - I agree that the logic holds.  I have one 
reservation and that is related to the potential dual usage of tags for 
(a) meta generation and (b) taglets generating consitent javadoc.  In 
the case of the service method I think it is good to keep the 
declaration at the level of the service implementation - but as you go 
on to say, there needs to be an eximination down the class hierachy.

> I needed adjust the AbstractTag class to resolve the type recursivley 
> in the inheritance hierachy, then some inheritance can be used in the 
> services. if a type can not be resolved I now throw a RuntimeException 
> to indicate the ant user what is wrong.
> just let me know and than I will send these patches.

Please do. 

Cheers, Steve.

> Kristian

Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message