Bug 33493

Summary: contribution to log4j: servlet diagnostic context
Product: Log4j - Now in Jira Reporter: weiqingh
Component: LayoutAssignee: log4j-dev <log4j-dev>
Status: NEEDINFO ---    
Severity: enhancement    
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: source code for printing servlet diagnostic info

Description weiqingh 2005-02-10 16:30:53 UTC
per the email thread below, I am attaching the source code for the 
solution to log the servlet session/request parameters and 
attributes. You guys can put it in the log4j sandbox (under the 
servlet package I assume). The code is well-documented and should 
compile with the build.xml used in the sandbox build. (It needs 
servlet.jar and log4j.jar).

Thanks,
Winston Huang

----- Original Message -----
From: "Jacob Kjome" <hoju@visi.com>
To: "Log4J Users List" <log4j-user@logging.apache.org>
Subject: Re: contribution to log4j: servlet diagnostic context
Date: Mon,  7 Feb 2005 11:19:35 -0600

>
>
> It might be a contrib or it could go into the logging-log4j-sandbox 
> to bake for
> a bit.  There are other classes there right now that depend on the 
> servlet and
> other API's, so the servlet dependency is not really an issue.  I would post
> code to the Dev list because I think you can attach .zip files there, which
> isn't the case on the user list.  Either that, or open a bug in Bugzilla and
> attach the code there.
>
>
> Jake
>
> Quoting Winston Huang <weiqingh@mail.com>:
>
> > it's difficult to filter the log messages based on the parameter values.
> > similar to the %t converter for printing thread name, how would you
> > selectively print the log statement based on the thread name? (i.e. logs
> > printed by thread called "thread foo" is logged but not logs from other
> > threads.) I think layout is purely meant to customize the log layout.
> >
> > if you really want to do it, you may resort to post-processing 
> filter such as
> > grep or chainsaw.
> >
> > I am not sure what and how authorization phase would help in this 
> case. Would
> > you shed some light on it?
> >
> > I am re-organizing the code and will publish it soon. Should I just post to
> > the user list or send it to some committer? My opinion is it belongs to
> > contribs. It needs the servlet library to compile. You don't want 
> to have any
> > of it in log4j.
> >
> > ----- Original Message -----
> > From: "Arthur Brown" <arthur.brown@gmx.net>
> > To: "Log4J Users List" <log4j-user@logging.apache.org>
> > Subject: Re: contribution to log4j: servlet diagnostic context
> > Date: Mon, 7 Feb 2005 11:13:26 +0100 (MET)
> >
> > >
> > > Hi Winston,
> > >
> > > I was looking also for a simple solution for the same situation.
> > >
> > > I thought, I could use MDC for this problem.
> > > You are absolutelly right it is specific to Aplication Server provider,
> > > wether the servlet request is handled by the same thread.
> > >
> > > The only thing you can use for sure is the session object.
> > >
> > > Another problem is to filter the logging statement
> > > with the key value paars, that contained in servlet session (or request).
> > >
> > > In your sample:
> > > only the logging events with userId=user_id_foo
> > > is looged and not for userId=user_id_bar
> > >
> > > For only session specific attributes, no servlet filter
> > > is nessesary, because the logging specific attributes can be
> > > writen during authorisation phase.
> > >
> > > My opinion, this stuff belongs to the core, because neither NDC, nor MDC
> > > could be used for this purpose.
> > >
> > > Could you please post your solution.
> > >
> > > Ciao
> > > Arthur Brown
> > >
> > >
> > > > all,
> > > >
> > > > I have encountered a lot of situations where I would like to 
> inspect the
> > > > servlet context information (such as session attributes, request
> > > attributes)
> > > > with the application logging, without touching the original 
> logging code.
> > > > It's similar to the %t conversion specifier in the 
> PatternLayout to print
> > > > out the current thread name. I ended up developing my own
> > > > solution using servlet filter and extension
> > > > to the layout classes. (I tried to use MDC and it didn't work 
> because the
> > > > servlet request could be handled by different threads.) The result is
> > very
> > > > interesting. For instance, if you have this logging statement in your
> > > servlet
> > > > application:
> > > >
> > > > logger.debug("this is a test");
> > > >
> > > > and you configure your pattern layout to be %p %S{userId} %m%n
> > > >
> > > > then the log output will be:
> > > >
> > > > DEBUG user_id_foo this is a test
> > > >
> > > > assuming the logging statement was executed inside a servlet 
> session with
> > > > userId set to user_id_foo. I have created two new conversion
> > > > specifiers %S and %R for attaching
> > > > servlet session and request attributes. Would it make sense that
> > > > I contribute it to Log4j in some way? I don't
> > > > believe it belongs to the core. Maybe I can put it under contribs? Any
> > > help is
> > > > appreciated. Thansk,
> > > > Winston
Comment 1 weiqingh 2005-02-10 16:31:59 UTC
Created attachment 14244 [details]
source code for printing servlet diagnostic info
Comment 2 Thorbjørn Ravn Andersen 2008-08-03 03:21:52 UTC
I think this is an excellent contribution but unit tests are needed for documentation purposes and to ensure that things are working correctly as part of the build process.

Could you provide a functional WAR file with sample output which can be refactored into something testable?