[5.0] Servlet logging and error messages

[Remy Maucherat <re...@apache.org>]

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: [5.0] Servlet logging and error messages

[Remy Maucherat <re...@apache.org>]

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: [5.0] Servlet logging and error messages

[Costin Manolache <cm...@yahoo.com>]

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org