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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
