[ http://jira.qos.ch/browse/LBCLASSIC-185?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-185: -------------------------------------- Useful stuff. Personally, I would also add the client's host name as well as the "X-Forwarded-For" field found in the http header. More generally though, the complete set of fields as defined in logback-access' PatternLayout would be of interest. See "Logback access" in [1]. The important point is that the fields you have defined, e.g. context path, user name etc. are highly useful for various purposes. BTW, since this is a relatively significant contribution, I would appreciate if you could sign the Contributor License Agreement [2[. [1] http://logback.qos.ch/manual/layouts.html [2] http://logback.qos.ch/cla.txt

Servlet filter which puts servlet-specific data into MDC --------------------------------------------------------

Key: LBCLASSIC-185 URL: http://jira.qos.ch/browse/LBCLASSIC-185 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.9.18 Reporter: Torsten Juergeleit Assignee: Logback dev list Attachments: logback-test.xml, RequestLogFilter.java, RequestLogFilterTest.java

Attached you can find a servlet filter which implements a strategy to put servlet-specific data into the SL4F MDC using the following keys: * {{slf4j.servlet.requestId}} - Unique ID of the single HTTP request handled by this filter * {{slf4j.servlet.sessionId}} - ID of the HTTP session this HTTP request is associated with or "" if no HTTP session was created yet * {{slf4j.servlet.contextPath}} - Web apps context path * {{slf4j.servlet.userName}} - Name of authenticated user or "" if no user is authenticated This data is removed after the request is processed. The following configuration parameters are supported by this filter: * {{maxSessionIdLength}} - limiting the HTTP session id length to a certain value, e.g. for WebLogic this could be 52 (default: -1 [unlimited]) To use this filter add the following lines to the {{web.xml file}}: <code> <filter> <filter-name>RequestLogFilter</filter-name> <filter-class>ch.qos.logback.classic.RequestLogFilter</filter-class> <init-param> <param-name>maxSessionIdLength</param-name> <param-value>52</param-value> </init-param> </filter><br> : <filter-mapping> <filter-name>RequestLogFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <code> An SLF4 Logger named {{ch.qos.logback.classic.RequestLogFilter}} is used to log the start end end of calling the filter chain. This information should go into a separate log file.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-185?page=com.atlassian.jira.plugin.syste... ] Ralph Goers edited comment on LBCLASSIC-185 at 2/5/10 8:42 AM: --------------------------------------------------------------- I don't have a problem with adding this to logback-examples but it isn't appropriate to add to logback-classic as there is no "correct" way to do this. For example,http://www.slf4j.org/extensions.html#event_logger shows code that works differently. In a lot of my implementations we have a hook into log in that captures most of the information in a Map that is stored in the session. Then the servlet filter just copies everything in the Map into the MDC and then adds a couple of request specific values. Furthermore, while it is a good goal to standardize some of these names in the MDC, doing that in a ServletFilter is horrible. We have implemented a class named RequestContext just for that purpose. It has all the key name constants and provides static methods such as public static String getRequestId() { return MDC.get(REQUEST_ID); } That class becomes the glue to bind things together, not the ServletFilter. One other issue with this code is that it puts the session id into the request. There is no good reason to do this and it should never be logged as it makes the application susceptible to session hijacking. See http://www.owasp.org/index.php/Top_10_2007-Broken_Authentication_and_Session... was (Author: rgoers@apache.org): I don't have a problem with adding this to logback-examples but it isn't appropriate to add to logback-classic as there is no "correct" way to do this. For example,http://www.slf4j.org/extensions.html#event_logger shows code that works differently. In a lot of my implementations we have a hook into log in that captures most of the information in a Map that is stored in the session. Then the servlet filter just copies everything in the Map into the MDC and then adds a couple of request specific values. Furthermore, while it is a good goal to standardize some of these names in the MDC, doing that in a ServletFilter is horrible. We have implemented a class named RequestContext just for that purpose. It has all the key name constants and provides static methods such as public static String getRequestId() { return MDC.get(REQUEST_ID); } That class becomes the glue to bind things together, not the ServletFilter.

Servlet filter which puts servlet-specific data into MDC --------------------------------------------------------

Key: LBCLASSIC-185 URL: http://jira.qos.ch/browse/LBCLASSIC-185 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.9.18 Reporter: Torsten Juergeleit Assignee: Ceki Gulcu Attachments: logback-test.xml, RequestLogFilter.java, RequestLogFilterTest.java

Attached you can find a servlet filter which implements a strategy to put servlet-specific data into the SL4F MDC using the following keys: * {{slf4j.servlet.requestId}} - Unique ID of the single HTTP request handled by this filter * {{slf4j.servlet.sessionId}} - ID of the HTTP session this HTTP request is associated with or "" if no HTTP session was created yet * {{slf4j.servlet.contextPath}} - Web apps context path * {{slf4j.servlet.userName}} - Name of authenticated user or "" if no user is authenticated This data is removed after the request is processed. The following configuration parameters are supported by this filter: * {{maxSessionIdLength}} - limiting the HTTP session id length to a certain value, e.g. for WebLogic this could be 52 (default: -1 [unlimited]) To use this filter add the following lines to the {{web.xml file}}: <code> <filter> <filter-name>RequestLogFilter</filter-name> <filter-class>ch.qos.logback.classic.RequestLogFilter</filter-class> <init-param> <param-name>maxSessionIdLength</param-name> <param-value>52</param-value> </init-param> </filter><br> : <filter-mapping> <filter-name>RequestLogFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <code> An SLF4 Logger named {{ch.qos.logback.classic.RequestLogFilter}} is used to log the start end end of calling the filter chain. This information should go into a separate log file.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.qos.ch/browse/LBCLASSIC-185?page=com.atlassian.jira.plugin.syste... ] Torsten Juergeleit commented on LBCLASSIC-185: ---------------------------------------------- Ralph is right here. Defining a generic servlet filter which caters all application-specific use cases isn't feasible. E.g. in our applications we only need the request id and the context path within the MDC. The request id is used as correlation id to aggregate data from different log files. The context path is used to split log files on a per-webapp base via SiftingAppender. All the other servlet-related stuff (including the session id) goes into the log file(s) created by the logger used within the servlet filter. This log file provides all the the correlation ids (request id, session id, context path) to combine the corresponding data from all the other log files from various sub-systems. To provide this kind of application-specific behaviour this servlet filter has to be extended. Moving the MDC handling (including the key names) into a separate class (without dependency to the servlet API) is a good point. Not storing the session id is another good point. Thanks for pointing out those issues. So you can close this ticket. Btw. how about my other feature request (with implementation) in http://jira.qos.ch/browse/LBCLASSIC-177 :-)

Servlet filter which puts servlet-specific data into MDC --------------------------------------------------------

Key: LBCLASSIC-185 URL: http://jira.qos.ch/browse/LBCLASSIC-185 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.9.18 Reporter: Torsten Juergeleit Assignee: Ceki Gulcu Attachments: logback-test.xml, RequestLogFilter.java, RequestLogFilterTest.java

Attached you can find a servlet filter which implements a strategy to put servlet-specific data into the SL4F MDC using the following keys: * {{slf4j.servlet.requestId}} - Unique ID of the single HTTP request handled by this filter * {{slf4j.servlet.sessionId}} - ID of the HTTP session this HTTP request is associated with or "" if no HTTP session was created yet * {{slf4j.servlet.contextPath}} - Web apps context path * {{slf4j.servlet.userName}} - Name of authenticated user or "" if no user is authenticated This data is removed after the request is processed. The following configuration parameters are supported by this filter: * {{maxSessionIdLength}} - limiting the HTTP session id length to a certain value, e.g. for WebLogic this could be 52 (default: -1 [unlimited]) To use this filter add the following lines to the {{web.xml file}}: <code> <filter> <filter-name>RequestLogFilter</filter-name> <filter-class>ch.qos.logback.classic.RequestLogFilter</filter-class> <init-param> <param-name>maxSessionIdLength</param-name> <param-value>52</param-value> </init-param> </filter><br> : <filter-mapping> <filter-name>RequestLogFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <code> An SLF4 Logger named {{ch.qos.logback.classic.RequestLogFilter}} is used to log the start end end of calling the filter chain. This information should go into a separate log file.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira