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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to