On Thursday 10 February 2005 18:27, Ceki G�lc� wrote: > UGLI is rather modest in its goals. It does not have the pretension of > initiating any major technological leap. JCL promises more than what it can > deliver. UGLI does what JCL does today but without the headaches.
This is a *very* good assessment. > Given the above, I am quite willing to support any third-party initiative, > going well beyond UGLI, that provides a reliable and well-tested solution. > Metro may be such a solution. That's really generous :o) We (Metro) have had some 'issues' with Log4J in the following areas; 1. API / management+spi / impl separation. --> Something that has been started in Log4J and will give us a lot of benfits. So all kudos to that. It is a BIG step in the right direction. 2. Logger "discovery" is the second area we are struggling with. As you know, I am a big fan of Inversion of Control, which basically disallow objects to 'get' and 'create' its own stuff, and should be handed objects to use. I see that a lot of stuff (RepositorySelectors) have happened in this field, which I have not studied (maybe that was what the request some 8-10months ago to change to 1.3 was all about?) and need to assess the implications of. Briefly, it looks like we can work with this from the "discovery" point of view. I really need to study this. 3. Runtime upgrades of Log4J itself! Metro has an ambition that most subsystems should be upgradable without shutting the whole thing down. "Upgrade" in this case is both a matter of getting the implementation of the various parts and core updated (e.g. bugfixes) but also that I can add custom stuff, such as new appenders or formatters. Static methods and final classes are generally a real PITA, since it prevents interception (without bytecode manipulation) of the references, making it difficult to get rid of the classes from memory. This issue will probably remain, and we can get back to this after the rest is in place (see below). I think that we will be able to create a LoggerRepository that ties into the Transit Plugin system, together with a clever build system add-on that can package Log4J in a way so that this works. Question; Does the LoggerRepository and RepositorySelector system have to be part of the configuration system (PropertiesConfigurator, DOMConfigurator et al), or are they responsible for their own configuration of Loggers, Appenders and Formatters? If the latter, then I think we have "a good deal" that we can work with, including getting a fairly good plugin system for Log4J (with the JDK1.4 constraint). If the configuration system is 'core', it may make it a bit trickier, as appenders/formatters are referenced directly with classnames. I still think some 'hack' could overcome that. However, as I mentioned privately, I am pretty busy with other stuff right now, so it will probably take 6-12months before something materializes... Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
