On May 30, 2010, at 2:12 PM, Curt Arnold wrote: > > On May 30, 2010, at 11:49 AM, Thorbjørn Ravn Andersen wrote: > >> There is one more thing that I would really like to see in log4j 2.0, namely >> the ability for a servlet to log to a servlet container using log4j (and in >> slf4j too but that is a different story). Currently that cannot be done, >> because there is no way for the code asking for the logger to pass a "this" >> reference to the logging framework. >> >> I would suggest that in log4j 2.0 the LoggerManager.getLogger() signature is >> changed to accept the class (as now), and a varargs of Objects. The objects >> are passed to the appender when needing to do the actual logging, allowing a >> ServletLoggerAppender to look for any object extending GenericServlet and >> invoke its log method. >> >> For client code it would mean that the logger object was retreived similar >> to: >> >> Logger log = Logger.getLogger(this.getClass(), this); >> >> >> We might even consider making the rule in log4j 2.0 that "the name of the >> logger is the full name of the class of the first object"[2]. In that case >> we could make do with: >> >> Logger log = Logger.getLogger(this); >> >> This would most likely also result in much other code being cleaner by >> allowing to drop the "getClass()" clause. >> >> What do you think? >> >> >> [1] >> http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/GenericServlet.html#log%28java.lang.String%29 >> >> >> [2] For backwards compatability instances of Class should be treated >> slightly different :) >> >> -- >> Thorbjørn Ravn Andersen "...plus... Tubular Bells!" >> > > > I don't have this in code or in the JIRA, but I have mentioned in recent > threads the idea of a user-supplied context object in logging calls. > Currently log4j has a thread associated context (the MDC and NDC) and there > are JVM level context (line ending separator), but there is no concept of a > user-supplied context unless embedded in the message parameter.
Passing the "context" as a parameter to logging calls is not the right way to handle this. Typically, only the top level classes are aware of the Servlet object or the ServletContext. All the calls underneath tend to be generic, such as everything in Apache Commons. The best way to handle this is to have different extensions of the LoggerContext that provide the information about the execution context. > > In this case, the logging call is operating in the "context" of the servlet > request, and you could do pass the servlet as the user-context object. A > servlet appender could check if the user context object was a Servlet and if > so delegate to its log method. We could also add patterns for %ipaddr, > %ipport, etc, that would attempt to recognize the user-context object and > extract that info if it could recognize the type. As I said below, the Appender could just as easily check the context. In my environment ipaddress, hostname, requestURI, etc are all part of the MDC and are passed from the web tier to all the services that are invoked so that all the logs can be correlated against the same user, request, transaction, etc. Adding these to the context object is problematic because the context is shared across requests which the MDC is not. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
