Hi, You know, though, I would argue that in the absence of any configuration all logging statements should be output to the console. So in a sense, I'd like to have BasicConfigurator.configure called automatically on the first logging statement if no other configuration has been done. Then you'd get the current warning that log4j hasn't been configured, and from that point on all output at DEBUG level to the console. The principle that a logging system should never hide/reject logging statements unless explicitly configured to do so is very strong. It trumps everything else a logging system should do, pretty much, including good performance.
Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: WJCarpenter [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 29, 2004 5:47 PM >To: Log4J Users List >Subject: RE: How Do I Find Out If log4j Has Been Configured? > >ys> That would be a good safe practice, yeah: if you're writing a >ys> library, and are relying on someone else to provide the >ys> configuration for logging, you should check that the logging was >ys> indeed configuration and if not take action (raise exception, >ys> configure it for your needs, whatever). > >The trouble is that a library writer doesn't generally know what a >good level of logging is for any particular caller. A reasonable >thing to do, very often, would be to say "OK, I'll just accept the >logging configuration of my environment since they know best". It can >be painful for the application writer to keep up with the wants and >needs of all the components s/he reuses, so a principal of "reasonable >defaults" is a hopeful expectation. > >ys> But if I now understand you correctly that you're talking about >ys> the case where not even BasicConfigurator.configure is called, >ys> then we have a different story and my -1 is misplaced perhaps. > >Yeah, that's the case I'm talking about: when no configuration is done >at all. Sorry if that wasn't clear. > >Quite often (I see this firsthand all the time), the person running >the application will say "I'll figure out logging later, just let me >run this application and I don't care right now if it doesn't log >anything". They are unaware that not having a configuration for log4j >gives them this performance penalty. In fact, when told this, you can >see a blinky look in their eyes, and they say "but the log has only a >couple lines about log4j ... how could I possibly be doing tons of >unnecessary logging?" When you explain to them that the log messages >get created and then thrown away, they just look at you like you're >slightly crazy. > >Anyhow, I more or less agree that any application savvy enough to call >BasicConfigurator.configure is savvy enough to ask for the logging it >wants. My use case is for applications that are completely unaware of >log4j because it comes in a library that is being reused. I don't >think it should be up to libraries to decide about that stuff, but >today the library author has to do something because of the >inconvenient log4j default. (It's also a bit obvious that log4j >doesn't anticipate someone doing this when you look at the contributed >code sample for doing the check.) > >It also slightly complicates the library to have to do the check since >you pretty much need to have the check for log4j configuration in some >static initializer for a class, and you have to make sure that class >is loaded before you do any logging stuff. Not the end of the world, >but slightly annoying. > >(Hey, things could be worse. The Apache Axis folks for a while >included a log4j.properties file in axis.jar, and it turned on a INFO >logging at the root level, IIRC. Well, it might not have been a ton >of logging for Axis, but not everybody uses the same conventions for >what to log and when. Their file defeated any normal "is it >configured yet?" check. The only cure was too delete that file from >axis.jar [which the Axis folks have done themselves in recent betas].) >-- >[EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 >38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
