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

On May 30, 2010, at 9: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!"
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 


---------------------------------------------------------------------
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