DO NOT REPLY [Bug 33493] New: - contribution to log4j: servlet diagnostic context

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33493>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33493

           Summary: contribution to log4j: servlet diagnostic context
           Product: Log4j
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Layout
        AssignedTo: log4j-dev@logging.apache.org
        ReportedBy: weiqingh@yahoo.com


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" <ho...@visi.com>
To: "Log4J Users List" <lo...@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 <we...@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" <ar...@gmx.net>
> > To: "Log4J Users List" <lo...@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

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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