Re: [5.0] Servlet logging and error messages
Remy Maucherat wrote: I'm working on the following changes: - Stripping out all the Catalina related part of the stack trace in the HTML generated by the ErrorReportValve; that eases debugging. +1 - When an exception occurs, and it is a ServletException, I think the root cause should be logged, not the external exception, which 99% of the time is useless. +1 - I strongly believe that all webapp triggered logging (init errors, service errors, etc) should go to the servlet container provided logger (ie Context.getLogger()). Right now, a significant amount is sent to commons-logging. I was aware that the intent was to switch the container itself to commons-logging (and I am +1 for it), but c-l or another generic logging framework such as log4j, is IMO not adapted to provide the webapp logging (same for the access log, obvioously). Comments ? I don't agree with the last point, but I right now I don't have the time to disagree :-) I'm +1 to have the logs related to a context go to the context log file - after the request is mapped to a context. Everything could go in the context's log and be controlled by a per-context config file. However I think the best solution would be to do that by writting some code in commons-logging or log4j that would implement the per-context logger. For example, as soon as we map to a context we can set a root logger associated with the current thread, and make sure the logger uses this logger to implement isLogEnabled() and log(). And IMO we should have ServletContext.log and the access log implemented as regular commons-logging calls. Since I don't think I'll have the time to do that in the next month, I'll just ask for more details on how are you going to do it and be +0 or -0. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Servlet logging and error messages
Howdy, - Stripping out all the Catalina related part of the stack trace in the HTML generated by the ErrorReportValve; that eases debugging. Hmm... As long as the full stack trace, including Catalina, is still in the log file, that's OK. I know the Catalina parts of the stack trace frequently have = 0 value, but I still feel better knowing the full stack trace is there. - When an exception occurs, and it is a ServletException, I think the root cause should be logged, not the external exception, which 99% of the time is useless. What about cases where someone constructs a ServletException with a message, without a root cause exception? - I strongly believe that all webapp triggered logging (init errors, service errors, etc) should go to the servlet container provided logger (ie Context.getLogger()). Ditto, +1. Right now, a significant amount is sent to commons-logging. I was aware that the intent was to switch the container itself to commons-logging (and I am +1 for it), but c-l or another generic logging framework such as log4j, is IMO not adapted to provide the webapp logging (same for the access log, obvioously). Curious: why is log4j not adapted / what's missing from it for this use-case? Yoav Shapira 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]
RE: [5.0] Servlet logging and error messages
hi , IS there is any way to Connect Database using DBCP.jar without giving username and password in the server.xml file. Doc tells that we can pass the uname and password in the getConnection() method of DataSource . But it is give me an Exception . Plese help me. sathya _ NRIs ahoy! Want to send money home? http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp Do it in a jiffy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Servlet logging and error messages
Shapira, Yoav wrote: Howdy, - Stripping out all the Catalina related part of the stack trace in the HTML generated by the ErrorReportValve; that eases debugging. Hmm... As long as the full stack trace, including Catalina, is still in the log file, that's OK. I know the Catalina parts of the stack trace frequently have = 0 value, but I still feel better knowing the full stack trace is there. The full trace of the root cause is now logged (instead of the full trace of the exception, which was not very useful IMO). The new display seems to me significantly easier on users (esp when using the request dispatcher a lot, which could have created huge stack traces in the past). - When an exception occurs, and it is a ServletException, I think the root cause should be logged, not the external exception, which 99% of the time is useless. What about cases where someone constructs a ServletException with a message, without a root cause exception? If there's no root cause, getRootCause returns null, and the original exception is logged. I have already implemented all that, so you can check with the CVS code. - I strongly believe that all webapp triggered logging (init errors, service errors, etc) should go to the servlet container provided logger (ie Context.getLogger()). Ditto, +1. And the container messages should go to c-l. Curious: why is log4j not adapted / what's missing from it for this use-case? Because log4j wasn't with Apache for Tomcat 4.0. Also, I believe TC's container logger can be configured more easily and consistently with other components. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Servlet logging and error messages
Howdy, The full trace of the root cause is now logged (instead of the full trace of the exception, which was not very useful IMO). The new display seems to me significantly easier on users (esp when using the request dispatcher a lot, which could have created huge stack traces in the past). Ahh, that makes more sense now that I've read it twice ;) Thanks. Curious: why is log4j not adapted / what's missing from it for this use-case? Because log4j wasn't with Apache for Tomcat 4.0. Also, I believe TC's container logger can be configured more easily and consistently with other components. Got it ;) Yoav Shapira 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]
Re: [5.0] Servlet logging and error messages
Costin Manolache wrote: I don't agree with the last point, but I right now I don't have the time to disagree :-) I'm +1 to have the logs related to a context go to the context log file - after the request is mapped to a context. Everything could go in the context's log and be controlled by a per-context config file. However I think the best solution would be to do that by writting some code in commons-logging or log4j that would implement the per-context logger. For example, as soon as we map to a context we can set a root logger associated with the current thread, and make sure the logger uses this logger to implement isLogEnabled() and log(). And IMO we should have ServletContext.log and the access log implemented as regular commons-logging calls. Since I don't think I'll have the time to do that in the next month, I'll just ask for more details on how are you going to do it and be +0 or -0. I know, I know, your arguments make sense. The problem I have with that is that the configuration is not consistent with the rest of the container configuration (while it should IMO be integrated). Another problem is that it's not finished, and another one is that we still need a lot of similar code for our specialized logs (aka, the access log). So that's why I plan to cut the thing in half and: - use c-l for all logging for the Tomcat core - use the Tomcat loggers for all webapp related logging Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Servlet logging and error messages
I'm working on the following changes: - Stripping out all the Catalina related part of the stack trace in the HTML generated by the ErrorReportValve; that eases debugging. - When an exception occurs, and it is a ServletException, I think the root cause should be logged, not the external exception, which 99% of the time is useless. - I strongly believe that all webapp triggered logging (init errors, service errors, etc) should go to the servlet container provided logger (ie Context.getLogger()). Right now, a significant amount is sent to commons-logging. I was aware that the intent was to switch the container itself to commons-logging (and I am +1 for it), but c-l or another generic logging framework such as log4j, is IMO not adapted to provide the webapp logging (same for the access log, obvioously). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
