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: [email protected] ReportedBy: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> To: "Log4J Users List" <[email protected]> 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 <[EMAIL PROTECTED]>: > > > 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" <[EMAIL PROTECTED]> > > To: "Log4J Users List" <[email protected]> > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
