hossman wrote: > > : a fan; but it's really not that important any way). Then, if someone > (like > : me :-) would like to configure logging with log4j then I am easily > empowered > : to do so by removing that jar and adding slf4j-log4j.jar. What I like > about > > This is the part of all the third party logging abstraction arguments i've > ever heard that I never understand -- if userA ruws webapp wyz.war in > "CoolioServletContainer then even if wyx.war uses SLF4J, and even > if userA uses slf4j-log4j.jar because userA want log4j to be the > underlying logging system, that won't change the fact that unless > CoolioServletContainer provides an alternate implementation of the > JUL LogManager, the default implementation is still being loaded by the > JVM, and some code somewhere (maybe a plugin to wyz.war, maybe another > webapp in the same servlet container, etc...) might use the JUL APIs to > log some info -- so userA needs to worry about those messages (or they go > to STDERR). >
1. I think it's VERY rare to find utility/library/framework code that logs to JUL (instead, JCL and increasingly SLF4J are used for such code). Come to think of it, I don't know of any at all using JUL; though of course there's got to be some ill-advised project that doesn't know better out there ;-P So needless to say, I've yet to run into this scenario despite all the open-source Java software I've encountered over the years. 2. If you're saying (from another message I responded to) that it's the container's job to handle the JUL configuration in a flexible manner, then wouldn't it be reasonable in this scenario to tell the container to direct JUL to whatever it is I want (log4j in this scenario)? 3. You mentioned logging from some other webapp that userA didn't write. If the container is so great at configuring JUL, then as I ask in #2, just let the container do it's JUL kung-fu thing. hossman wrote: > > using an alternate logging framework does't make JUL logging go away -- > it's still there, it's the 3000lb gorilla in the corner. it may be > sleeping, but that doesn't mean some code somewhere isn't going to wake it > up at some point -- you might as well acknowledge it and deal with it. > > bringing in another gorilla doesn't make the first one go away > I'm not sure why a gorilla is a suitable analogy for this... but see #2 above any way. ~ David -- View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16973118.html Sent from the Solr - Dev mailing list archive at Nabble.com.
