logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Improving log4j so it can easily be used with servlet logging
Date Sun, 30 May 2010 21:12:47 GMT

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.

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.


On May 30, 2010, at 2:34 PM, Ralph Goers wrote:

> Wouldn't it make more sense for the LoggerContext to have a reference to the ServletContext?
The Appender could then do 
> 
> if (getContext().getServletContext() != null) {
>  getContext().getServletContext().log(event.getFormattedMessage());
> }
> 
> Note that if the servlet adds its name to the MDC then all log records will have this
available.  
> 
> To be honest though, I would have expected the desire would be to have the ServletContext's
log methods route to Log4j, not the other way around.  
> 
> Ralph

The MDC is associated with the thread and a single thread over its lifetime may deal with
multiple servlets.  Using the MDC for user-supplied context then requires a decent amount
of less than foolproof gymnastics to make sure that things don't linger in the MDC outside
of the scope of the call.

We should capture this in JIRA. 



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


Mime
View raw message