Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (athena.apache.org: domain of curt.arnld@gmail.com
 designates 74.125.83.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=fWykDrmuP33Zb2VeKhzLOTx23I8gazMaz41BCUZ5x7UrNzkLCGLfhVh3cluscmTN7a
         3vBCv8nhd57OWoMNfV4HPQxH4iscDuFR7RkicoiRhcV47ytl6eRMIOxXCFDelNoxLpxW
         fNyhqjLxPUOoYuvAuAF9n4ENLvG+vJqKjeQk4=
Sender: Curt Arnold <curt.arnld@gmail.com>
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: Improving log4j so it can easily be used with servlet logging
From: Curt Arnold <carnold@apache.org>
In-Reply-To: <4C029703.7020806@gmail.com>
Date: Sun, 30 May 2010 16:12:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9625AD8C-B009-4E2E-8E66-93F139DAC203@apache.org>
References: <4C029703.7020806@gmail.com>
To: "Log4J Developers List" <log4j-dev@logging.apache.org>


On May 30, 2010, at 11:49 AM, Thorbj=F8rn 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.
>=20
> 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.
>=20
> For client code it would mean that the logger object was retreived =
similar to:
>=20
>   Logger log =3D Logger.getLogger(this.getClass(), this);
>=20
>=20
> 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:
>=20
>  Logger log =3D Logger.getLogger(this);
>=20
> This would most likely also result in much other code being cleaner by =
allowing to drop the "getClass()" clause.
>=20
> What do you think?
>=20
>=20
> [1] =
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/GenericServlet.html#lo=
g%28java.lang.String%29=20
>=20
> [2] For backwards compatability instances of Class should be treated =
slightly different :)
>=20
> --=20
>  Thorbj=F8rn Ravn Andersen  "...plus... Tubular Bells!"
>=20


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=20
>=20
> if (getContext().getServletContext() !=3D null) {
>  getContext().getServletContext().log(event.getFormattedMessage());
> }
>=20
> Note that if the servlet adds its name to the MDC then all log records =
will have this available.  =10
>=20
> 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. =20
>=20
> 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.=20


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