avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [Mx4j-devel] Logger
Date Sat, 17 Aug 2002 04:19:14 GMT
Simone,

>>>Am I missing something here ?
>>> 
>>>
>>>      
>>>
>>Kinda.  I think the Models honored by the two interface/impl 
>>Logger APIs 
>>at Apache are way superior :
>>[...]
>>
>Ok, will take a look. Thanks for reminding me these pointers !
>
You're welcome.

>> Do-the-Simplest-Thing works very well (I work for an 
>>international XP 
>>adocating consultancy) when you can refactor all uses of that 
>>thing as 
>>and when you need to whithout seeking permission.  Can you 
>>change this 
>>now without upsetting users?  Possibly not, therefor Do the simpelst 
>>thing does not apply. The API creater does have to do a lot of un-XP 
>>modelling and trial-and error before publishing the API.
>>    
>>
>
>I would be very interested in what you intend for "un-XP modelling", especially when compared
to the TDD (test driven development) practice of XP.
>Although being in vacation, I'm reading Pete McBreen's "Questioning XP", so I find interesting
the idea of "un-XP modelling".
>Do you mind to expand on that, if you have some time ?
>
Well I am not knocking XP really.  Test first is applicable to both the 
API writer and non-API applicaion.  When I say un-XP modelling, I mean 
over-modelling, or spending too long thinking about model is un-XP. 
 Simplest thing, and a hundred refactors is the best way to guarantee 
success in app building.  Maintaining backwards compatability and decent 
modelling are the best way to guarantee sucess for an API or a reusable 
tool/library.  That last mitigated by how many external users of that 
API are there.  If you know all four developers using MX4J in external 
projects (me, him, her and them) then you can gain permission for 
breaking backwards compatability.  If your audience is tens of thousands 
(say like for the SAX API), you only move forwards with full back-compat 
for 1.x and push major changes into a 2.0 release.

>>[...]
>>    
>>
>>My nearly perfect-world scenarion would be Inversion of Control 
>>inspired.  This....
>>
>>       MX4JLoggerAdapter.setLogger(getMyActualLogger());
>>       mx4j.log.Log.redirectTo(new MX4JLoggerAdapter());
>>       MBeanServerFactory.createMBeanServer( "Phoenix" );
>>
>>... would be replaced by...
>>
>>       MBeanServer mbs = 
>>MBeanServerFactory.createMBeanServer( "Phoenix" );
>>       mbs.setLogger(new MX4JLoggerAdapter(getMyActualLogger()));
>>       mbs.start();
>>    
>>
>
>Eh, I know. But is not possible, since MBeanServer does not have a setLogger(...) method.
>
I know, it is the type of design I would hope to see.  The nascent 
MBeanServer is decorated with a logger then started (IoC pattern).

>>To be honest though, singleton or a Commons-Logger model, or an 
>>Avalon-Framework Logger would be fine for me.
>>    
>>
>
>I know, but I don't want to make the MX4J implementation depending on other jars. And
this forces me to write an MX4J logger wrapper that at minimum does System.out.println, and
allows plugging of other logging systems.
>It seems to me that this is exactly the purpose of Commons-Logger, but as I've said, I
don't want mx4j.jar to depend on commons-logging.jar
>
It's is not the biggest of crimes to be dependant on external jars dude. 
 Tomcat depends on ten or so.  Depending on one or two is fine...?

Besides you could still go with a complete IoC like interface for MX4J 
with your own LogEnabled, Startable and we (Apache's Avalon-Phoenix 
team) could just adapt again.  That said we're looking to see our 
Avalon-Framework jar more widely used.  It is fairly benign.

>><controversy>
>>My real perfect-world scenario would be a a full component design 
>>leveraging all the lifecycle methods of Avalon-Framework
>>( 
>>http://jakarta.apache.org/avalon/framework/guide-patterns-in-a
>>valon.html 
>>)  The MX4J server could run completely independantly ( it just needs 
>>the Avalon-framework jar ), or we could mount it's components 
>>insde and 
>>enterprise container like Phoenix.  For the record nothing suggested 
>>here would preclude it's deployment in any other container
>></controversy>
>>    
>>
>
>Will take a look also at this.
>
>Paul, thanks for the useful insights.
>  
>
You're welcome & keep up the good work.

Cheers,

- 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>


Mime
View raw message