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]
