logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Improving log4j so it can easily be used with servlet logging
Date Sun, 30 May 2010 21:25:50 GMT

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.

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message