> Theres not even a need to go to that extent. I sent a description to Mauro how > you could integrate Commons Logging into our own logging by some tricky use > of thread locals and stuff. Mauro - do you still have that mail? >
Peter, copy of email below ... On Wed, 4 Dec 2002 08:35, Mauro Talevi wrote: >> Peter Donald wrote: > >>> >In the latest CVS you can loadLogManager using; >>> >a) original Phoenix logging spec >>> >b) Excalibur-Logger for LogKit >>> >c) Log4JConfLoggerManager for Log4j >>> > >>> >You just need to set the version attribute on <logs/> element to "1.0" for >>> >(a), "1.1" for (b) and log4j for (c) > >> >> great! that's what I was proposing - glad it's already done :-) It is still missing the JDK1.4 version though - so feel free to submit that ;) >> I'm a bit confused - does this violate the IOC principle or not? yes it does ... but IOC is not a sacred cow. I regularly break it if it gets in my way ;) ie These things are a tradeoff and sometimes it is useful to use and sometimes it is not. I need to rant about this on avalon-dev as a couple of people have been talking to me about this recently. Just for your info there is large chunks of Avalon code that break IOC where approriate. ie If you look at a lot of the files that are i18n'ed they will statically cache a references to resources at the top of the file. This breakes IOC as the container should provide the i18n resources but the reality of the situation is that it is not often that i18n resources need to be managed by container so the benefits of IOC are not worth the added complexity. >> phoenix.components.logger.DefaultLogManager.createHierarchy() >> instantiates a Logger to the Sar >> but does it hold this instance anywhere? not at the moment but you could hold it in a thread local variable... >> Maybe I'm making unwarranted parallel with webapps but if I bring up >> Tomcat and I instantiate something >> in an init servet and put it the app context I can retrieve it elsewhere >> for that app via a given key. >> Does Context in Phoenix work in a similar way? not at this point in time. >> If so, I can be sure that I got the instance of the Logger that was >> instantiated when the Sar was deployed >> (and none other - eg for different apps). It would be equivalent to >> extending AbstractLogEnabled, would it not? It would not be equivelent but it would allow easier integration with non-Avalon logging codebases. And repeating something I sent in an earlier mail :) - the way i think that this should occur is -------------------------------------------------------------------------------- 1. Create a thread local variable to hold the current applications base logger 2. Create a commons-logging LogFactory that retrieves the logger from that thread local 3. Make sure the thread local is always set - even when coming in from outside the application (This is done via ThreadContext code and is a PITA to do so I can do it if you like). 4. Somehow register that factory??? I believe that commons-logging does it by loading a file such as META-INF/services/org.apache.commons.logging.LogFactory.properties to find classname of log factory. So what we could do is to register a factory via that mechanism and in theiory that should work. -------------------------------------------------------------------------------- -- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
