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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
