DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-02 01:32 --- As discussed in the thread on this bug report, the attempt to configure Log4J has been removed from Log4JLogger and Log4JCategoryLog. Fixed in nightly build 20030402. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2003-03-31 07:39 --- Log4j does not provide a default configuration. However, if at static initailization time, log4j can find a resource called log4j.xml or log4j.properties, it will use that configration file. The name of the files to search for can be specified by the user. I hope this answers the question, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 22:14 --- Why now change the behavior of the Log4JFactory to not perform any default initialization, BUT extend commons-logging to allow for custom initialization classes that can be declared in the commons-logging properties? org.apache.commons.logging.LogInitializer=whatever class you want to do initialization This gives commons-logging users of all log packages the opportunity to initialize correctly according to the log package being used and/or product it is being used within. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 23:22 --- I'd be happy with the latest proposal, esp. if log4j did nothing beyond calling the log initializer class. At least then I'd have control over having it do or not do initialization. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 10:30 --- The functionality I desire is the functionality in version 1.0 of commons-logging. That functionality is that commons-logging makes no attempt in any way to apply a default configuration to log4j. And that is the fundamental issue I have against having commons-logging attempt to put in a default configuration - it shouldn't. As a developer or deployer, I should be smart enough to know what I want my logging system to acheive. Again, quoting from the commons-logging documentation: The basic principle is that the user is totally responsible for the configuration of the underlying logging system. Commons-logging should not change the existing configuration. Existing configuration means whatever I've done to configure my logging package, including letting it default. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 06:55 --- But what should the semantics be for an application that uses a component that uses commons-logging that doesn't have a root appender configured? When the component goes to log, it will get an unconfigured category, and will generate errors. Wrong working assumption! If the logger named org.apache.commons.httputils is configured (it has an attached appender) and, assuming httputils only uses loggers under org.apache.commons.httputils, logging from httputils will *not* generate errors even if the root logger is not configured. Wrong assumptions = wrong conclusions. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2002-10-22 17:44 --- Not for me. I use log4j, but it's not configured using the default configuration mechanism. I configure explicitly, and not always from a property file name 'log4j.properties'. How about this? If we're searching for a log implementation, that is,an implementation has not been set explicitly, and the log4j Root appender is not configured, move on to the next in the search list? I'd also like to know what Steven Caswell's desired behavior is? He's got the use case where Root is unconfigured, but other loggers are. What should a random log category do in this case. Be default, I believe Log4J will print out error messages, which is, in my opinion, undesireable behavior. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 02:52 --- I didn't mean that log4j in an application couldn't be used without a root logger configured. That's well within scope for log4j and a self contained application. But what should the semantics be for an application that uses a component that uses commons-logging that doesn't have a root appender configured? When the component goes to log, it will get an unconfigured category, and will generate errors. It might not even be the component that's of interest to the application. e.g. httpclient may use collections, which uses logging. By leaving log4j unconfigured, we force the application to become interested in logging. And removing log4j is not always feasible. It may be present to support other apps that are interested in logging. Getting log4j warnings just because you start using a commons component seems wrong. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13201] - Remove default log4j configuration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201 Remove default log4j configuration --- Additional Comments From [EMAIL PROTECTED] 2002-10-06 01:10 --- In practice, I think this means changing the selection mechanism for the logging system to use. It's not enough to see that log4j is present. If the root logger in log4j is not configured, then log4j can't be used. Otherwise you get errors printed out instructing you to correctly configure the logging system. OTOH, I also think it's a logical error to use log4j without configuring the root logger, even if only to send everything to the null appender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
