Appenders Problem
Hi All; I would like to write to a specific file when logging from a specific class. Below is my properties file. The class that needs the special behavior is in the model.notification package. It should be handled with the emailAppender, which in turn should only write INFO messages to the email.html file. But what happens is email.html gets everything and fw.html gets everything plus some duplicate entries. What am I doing wrong? Thanks, Luke log4j.rootLogger=debug, generalAppender, emailAppender #class specific loggin log4j.category.model.notification=INFO, emailAppender log4j.additivity.model.notification=false log4j.category.beans=DEBUG, generalAppender log4j.category.model=DEBUG, generalAppender log4j.category.model.writers=DEBUG, generalAppender log4j.category.servlet=DEBUG, generalAppender #general appender properties log4j.appender.generalAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.generalAppender.File= //usr/local/tomcat/logs/fw/fw.html log4j.appender.generalAppender.MaxFileSize=100KB log4j.appender.generalAppender.DatePattern='.'-MM-dd log4j.appender.generalAppender.MaxBackupIndex=3 #email appender properties log4j.appender.emailAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.emailAppender.File= //usr/local/tomcat/logs/fw/email.html log4j.appender.emailAppender.MaxFileSize=300KB log4j.appender.emailAppender.DatePattern='.'-MM-dd log4j.appender.emailAppender.MaxBackupIndex=3 #general appender layout log4j.appender.generalAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.generalAppender.layout.LocationInfo=true log4j.appender.generalAppender.layout.Title=FW Application Log #email appender layout log4j.appender.emailAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.emailAppender.layout.LocationInfo=true log4j.appender.emailAppender.layout.Title=FW Email Log
RE: Appenders Problem
If you remove 'emailAppender' from your log4j.rootLogger config then part of your problem should be fixed. I had a similar situation and used the following code: log4j.rootLogger=DEBUG, EXTERNAL log4j.logger.internal=DEBUG,INTERNAL log4j.additivity.internal=false where I defined 2 separate appenders and every logger starting with the string 'internal.'... would just go to the INTERNAL appender. I think this is similar to the problem you have now? matt -Original Message- From: Luke [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 5:32 AM To: log4j-user@logging.apache.org Subject: Appenders Problem Hi All; I would like to write to a specific file when logging from a specific class. Below is my properties file. The class that needs the special behavior is in the model.notification package. It should be handled with the emailAppender, which in turn should only write INFO messages to the email.html file. But what happens is email.html gets everything and fw.html gets everything plus some duplicate entries. What am I doing wrong? Thanks, Luke log4j.rootLogger=debug, generalAppender, emailAppender #class specific loggin log4j.category.model.notification=INFO, emailAppender log4j.additivity.model.notification=false log4j.category.beans=DEBUG, generalAppender log4j.category.model=DEBUG, generalAppender log4j.category.model.writers=DEBUG, generalAppender log4j.category.servlet=DEBUG, generalAppender #general appender properties log4j.appender.generalAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.generalAppender.File= //usr/local/tomcat/logs/fw/fw.html log4j.appender.generalAppender.MaxFileSize=100KB log4j.appender.generalAppender.DatePattern='.'-MM-dd log4j.appender.generalAppender.MaxBackupIndex=3 #email appender properties log4j.appender.emailAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.emailAppender.File= //usr/local/tomcat/logs/fw/email.html log4j.appender.emailAppender.MaxFileSize=300KB log4j.appender.emailAppender.DatePattern='.'-MM-dd log4j.appender.emailAppender.MaxBackupIndex=3 #general appender layout log4j.appender.generalAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.generalAppender.layout.LocationInfo=true log4j.appender.generalAppender.layout.Title=FW Application Log #email appender layout log4j.appender.emailAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.emailAppender.layout.LocationInfo=true log4j.appender.emailAppender.layout.Title=FW Email Log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j stops logging at console
This problem was fixed in (I believe) jBoss 4.0.2. Of course in that
same versions they screwed up other stuff... (i.e.: Hibernate would no
longer work if you had it in your application) so you may or may not
want to use that version anyway. But they are aware of the issues and I
hope they will eventually fix all these problems.
Good luck.
Bruno Melloni
Director of Software Architecture
Akuratus Corporation
1333 N. Stemmons Fwy, Suite 110
Dallas, Texas 75207
Phone: 469.227.0920
Fax: 469.227.0967
[EMAIL PROTECTED]
www.akuratus.com
[EMAIL PROTECTED] 5/16/2005 11:38:55 AM
JBoss, by current design, only provides for one logging context (ie
LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
special CONSOLE appender that maps the System.out and System.err
streams.
If you do any kind of configuration after JBoss starts up that affects
the
console appender OR affects loggers that have been defined in the
JBoss
log4j.xml file, then it will affect the output to the log files.
Especially
Console, do not mess with Console. Also, if your log4j code ever
calls
LoggerRepository.shutdown() during a redeploy, then logging will be
hosed as
well.
JBoss really needs to provide a better mechanism to allowing web apps
and
ejb's to do their own logging.
Log4j does provide some layering of configuration where you can set
up
your own loggers and appenders as long as they are not references by
the
first/base configuration file. Or you can just add your logging stuff
to
the JBoss log4j.xml file directly.
You may also find the following link useful, but I don't know if anyone
has
gotten to work correctly in JBoss or not. Seems to me that to be
completely
efficient, it would need to be supported pretty deep in the JBoss
log4j
initialization.
http://www.qos.ch/logging/sc.jsp
-Mark
-Original Message-
From: Clandes Tino [mailto:[EMAIL PROTECTED]
Sent: Monday, May 16, 2005 6:51 AM
To: log4j-user@logging.apache.org
Subject: log4j stops logging at console
Hello all.
I am facing the problem with log4j usage in two
separate applications.
I am using CONSOLE appenders for both of them.
Applications are started separately (in two shell
windows). The first app (App1) is assembled as EAR and
deployed under JBoss (it uses log4j.jar from
JBoss/server/default/lib and initializes log4j through
MBean, where appenders and loggers are configured).
Here is the method in MBean that configures log4j in
App1:
---
private void initLog4j() throws ConfigurationException
{
final Properties props = new Properties();
props.setProperty(log4j.category.com.myapp,
DEBUG, CONSOLE, FILE);
props.setProperty(log4j.appender.CONSOLE,org.apache.log4j.ConsoleAppend
er);
props.setProperty(log4j.appender.CONSOLE.layout,org.apache.log4j.Patter
nLayout)
props.setProperty(log4j.appender.CONSOLE.layout.ConversionPattern,%d{IS
O8601}
%-5p [%c{1}] [%X{user}] - %m%n);
props.setProperty(log4j.appender.FILE,org.apache.log4j.RollingFileAppen
der);
props.setProperty(log4j.appender.FILE.File,
getConfigurationSetting(LOG_FILE));
props.setProperty(log4j.appender.FILE.MaxFileSize,
getConfigurationSetting(MAX_FILE_SIZE));
props.setProperty(log4j.appender.FILE.MaxBackupIndex,
getConfigurationSetting(MAX_BACKUP_FILE));
props.setProperty(log4j.appender.FILE.layout,org.apache.log4j.PatternLa
yout);
props.setProperty(log4j.appender.FILE.layout.ConversionPattern,%d{ISO86
01}
%-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
%m%n);
PropertyConfigurator.configure(props);
}
App1 uses A.jar and B.jar from App2 in compilation and
runtime. Both jars are placed in sar archive and
deployed in default/deploy folder under Jboss.
The other (App2) is RMI Server application deployed
separately (it uses another log4j-1.2.8.jar placed in
its classpath). A.jar and B.jar are in its classpath.
App2 configures log4j by log4j properties file:
log4j.category.CONSOLE = , aCONSOLE
log4j.appender.aCONSOLE =
org.apache.log4j.ConsoleAppender
log4j.additivity.CONSOLE=false
log4j.appender.aCONSOLE.ImmediateFlush=true
log4j.appender.aCONSOLE.layout=org.apache.log4j.PatternLayout
--
Both applications are physically on the same machine.
The problem occurs when some class from App1 invokes a
class from B.jar. Then logging disappears from console
window of App1. No further message in log appears.
However logging into file works OK.
My question is:
What can cause such behavior?
Thanx for the hint in advance.
Best regards
Milan
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
-
To unsubscribe, e-mail:
Re: log4j stops logging at console
Hello people, here is the scenario, which causes console logging to stop. Remote application (RMI server App), which is made by third party is started by batch file. Configuration file for log4j is found during startup and loggers are created, by using custom log4j.loggerFactory I entered some debug statements and saw that loggers are loaded with classLoader [EMAIL PROTECTED] Maybe it is important to tell you that there is used bad practice to have almighty class with many static properties, among which are the loggers. The second side of story is my client ear application under JBoss. Classes in my application depend on classes from RMI Server App, they need to have them in classpath in compile time. But in the runtime, classes from RMI server are not deployed anywhere else. Jboss is started with expanded JBOSS_CLASSPATH variable, changed in run.bat, containing paths to those classes. During startup, my MBean loaded by JBoss classloader [EMAIL PROTECTED] tries to connect to RMI Server and to obtain some remote class. But then above mentioned class on RMI Server side (containing constants and loggers as static members) is loaded again, this time with [EMAIL PROTECTED] Configuration file for log4j is parsed again and after PropertyConfigurator.configureAndWatch(s, 6L), I lose logging on Jboss CONSOLE, but logging to file remains. I hope, I gave you enough information. Any help, suggestion or hint would be more than welcome. Best regards Milan ___ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[INFO] Log4j Release Overview
The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging http session identifying information
If I understand correctly, you want to set session/user specific information per request? Since the MDC is stored in ThreadLocal, I think you will need to use a servlet filter to set and unset the MDC for each request. And yes, how threads are assigned to handle requests, etc is very container specific. So, setting and unsetting the MDC with each request is a good thing. I cannot remember offhand if there is already an MDC related servlet filter in the log4j-sandbox. You might want to take a quick look and use it as an example. -Mark - Original Message - From: Mark Lybarger [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 5:47 AM Subject: logging http session identifying information I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc-community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Appenders Problem
Responding to my own thread: I made the change below to my props file and everything is fine now. #general stuff log4j.logger.model.notification=INFO, emailAppender log4j.additivity.model.notification=false log4j.logger.beans=DEBUG, generalAppender log4j.logger.model=DEBUG, generalAppender log4j.logger.model.writers=DEBUG, generalAppender log4j.logger.servlet=DEBUG, generalAppender #general appender properties log4j.appender.generalAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.generalAppender.File= //usr/local/tomcat/logs/fw/fw.html log4j.appender.generalAppender.MaxFileSize=100KB log4j.appender.generalAppender.DatePattern='.'-MM-dd log4j.appender.generalAppender.MaxBackupIndex=3 #email appender properties log4j.appender.emailAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.emailAppender.File= //usr/local/tomcat/logs/fw/email.html log4j.appender.emailAppender.MaxFileSize=300KB log4j.appender.emailAppender.DatePattern='.'-MM-dd log4j.appender.emailAppender.MaxBackupIndex=3 #general appender layout log4j.appender.generalAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.generalAppender.layout.LocationInfo=true log4j.appender.generalAppender.layout.Title=FW Application Log #email appender layout log4j.appender.emailAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.emailAppender.layout.LocationInfo=true log4j.appender.emailAppender.layout.Title=FW Email Log - Original Message - From: Luke [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 8:32 AM Subject: Appenders Problem Hi All; I would like to write to a specific file when logging from a specific class. Below is my properties file. The class that needs the special behavior is in the model.notification package. It should be handled with the emailAppender, which in turn should only write INFO messages to the email.html file. But what happens is email.html gets everything and fw.html gets everything plus some duplicate entries. What am I doing wrong? Thanks, Luke log4j.rootLogger=debug, generalAppender, emailAppender #class specific loggin log4j.category.model.notification=INFO, emailAppender log4j.additivity.model.notification=false log4j.category.beans=DEBUG, generalAppender log4j.category.model=DEBUG, generalAppender log4j.category.model.writers=DEBUG, generalAppender log4j.category.servlet=DEBUG, generalAppender #general appender properties log4j.appender.generalAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.generalAppender.File= //usr/local/tomcat/logs/fw/fw.html log4j.appender.generalAppender.MaxFileSize=100KB log4j.appender.generalAppender.DatePattern='.'-MM-dd log4j.appender.generalAppender.MaxBackupIndex=3 #email appender properties log4j.appender.emailAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.emailAppender.File= //usr/local/tomcat/logs/fw/email.html log4j.appender.emailAppender.MaxFileSize=300KB log4j.appender.emailAppender.DatePattern='.'-MM-dd log4j.appender.emailAppender.MaxBackupIndex=3 #general appender layout log4j.appender.generalAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.generalAppender.layout.LocationInfo=true log4j.appender.generalAppender.layout.Title=FW Application Log #email appender layout log4j.appender.emailAppender.layout=org.apache.log4j.HTMLLayout log4j.appender.emailAppender.layout.LocationInfo=true log4j.appender.emailAppender.layout.Title=FW Email Log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [INFO] Log4j Release Overview
So what's the difference between 1.2.8 and 1.2.12 versions?, are we going back on version numbers?. I am confused srini -Original Message- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 12:34 PM To: log4j-user@logging.apache.org Subject: [INFO] Log4j Release Overview The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - 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]
RE: [INFO] Log4j Release Overview
The version number is 1.2.12, not 1.2.1.2, so 1.2.12 will be a newer version than 1.2.8. BTW, the latest released version is 1.2.9. Since we have not decided on the complete set of bug fixes yet, I can't answer this with complete certainty. It will contain the change to support a new level, TRACE, one level below DEBUG. -Mark -Original Message- From: Chennamaraja, Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 10:42 AM To: Log4J Users List Subject: RE: [INFO] Log4j Release Overview So what's the difference between 1.2.8 and 1.2.12 versions?, are we going back on version numbers?. I am confused srini -Original Message- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 12:34 PM To: log4j-user@logging.apache.org Subject: [INFO] Log4j Release Overview The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging http session identifying information
i want to log the session id, and any other info from the session that i choose so that i can sort my logs per session. i'll check out the sandbox. On 5/18/05, Mark Womack [EMAIL PROTECTED] wrote: If I understand correctly, you want to set session/user specific information per request? Since the MDC is stored in ThreadLocal, I think you will need to use a servlet filter to set and unset the MDC for each request. And yes, how threads are assigned to handle requests, etc is very container specific. So, setting and unsetting the MDC with each request is a good thing. I cannot remember offhand if there is already an MDC related servlet filter in the log4j-sandbox. You might want to take a quick look and use it as an example. -Mark - Original Message - From: Mark Lybarger [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 5:47 AM Subject: logging http session identifying information I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc-community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logging http session identifying information
There is an example of putting stored cookie information into the MDC. You could easily modify it to use information from the session instead. http://cvs.apache.org/viewcvs.cgi/logging-log4j-sandbox/src/java/org/apache/ log4j/servlet/CookieMDCFilter.java?view=markup It doesn't do anything to remove the MDC information after the next filter in the filter chain completes, so it might be a good idea to do that. That way you don't have wayward MDC info sticking around in the thread local getting reported later in some unrelated request context. I would do that in a final block if possible to guarantee it gets removed. hth, -Mark -Original Message- From: Mark Lybarger [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:19 PM To: Log4J Users List Subject: Re: logging http session identifying information i want to log the session id, and any other info from the session that i choose so that i can sort my logs per session. i'll check out the sandbox. On 5/18/05, Mark Womack [EMAIL PROTECTED] wrote: If I understand correctly, you want to set session/user specific information per request? Since the MDC is stored in ThreadLocal, I think you will need to use a servlet filter to set and unset the MDC for each request. And yes, how threads are assigned to handle requests, etc is very container specific. So, setting and unsetting the MDC with each request is a good thing. I cannot remember offhand if there is already an MDC related servlet filter in the log4j-sandbox. You might want to take a quick look and use it as an example. -Mark - Original Message - From: Mark Lybarger [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 5:47 AM Subject: logging http session identifying information I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc- community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4 J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark - 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]
