RE: webapplication logging - one log file per user
Be careful about using the global context... In a scenario where you have two users logged in simultaneously wouldn't you have problems? From: Shekar [mailto:shivaraj...@gmail.com] Sent: Monday, November 30, 2009 9:21 AM To: Log4NET User Subject: Re: webapplication logging - one log file per user Well, Thanks to everyone for the suggestions. At last I got what I wanted. Following were the steps I followed: 1. Set the file name dynamically using GlobalContext [you can ThreadContext as well] property which the user who logged in. 2. Load the config file using XmlConfigurator.Configure(ConfigFile). 3. Now use GetLogger(type()) This working is perfectly as expected. Thanks again. Raj. On Mon, Nov 30, 2009 at 8:36 PM, Walden H. Leverich wald...@techsoftinc.com wrote: I understand it's not your exact requirement, but what about including the user name in each message logged, but pushing it into the NDC? We have a similar requirement to include the client name in our application, and we use a single log file (per day) but every request starts with a NDC.Push(ClientID) step. Then it's a trivial job to grep the log file for the client name. Likewise, when you need to see the log file for JoeUser you could just grep for JoeUser. If you need them maintained then you could just split the files after the fact by user name. -Walden -- Walden H Leverich III Tech Software BEC - IRBManager (516) 627-3800 x3051 wald...@techsoftinc.com http://www.TechSoftInc.com http://www.techsoftinc.com/ http://www.IRBManager.com http://www.irbmanager.com/ Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) From: Shekar [mailto:shivaraj...@gmail.com] Sent: Friday, November 27, 2009 11:47 PM To: log4net-user@logging.apache.org Subject: webapplication logging - one log file per user Hi, Please help me with this query in using log4net. I am using log4net in mhy we application. I am facing issues in configuring log4net to log errors at user level. That is, If user X logs in, I like to create file name X and all error for user X should be written in X.log. Siilarly if Y user logs in the log file should be in name of Y.log and the most important point to note is, they could log in concurrently. I tried the luck by creating log files whose name would be framed dynamically as soon as the user logs in. But issue here, if they are not using the application at the same time, the log files are creeated with correct name and writing as expected, but if both users have active sessions, log file is created only for user who FIRST logged in and error of second user has been recorded in log file that is created for FIRST user. Please help me in this. Thanks much.
RE: Wrapping Log4Net
Oops, I didn't quite finish one sentence below. Meant to say The
practical challenge was that I had to choose between only exposing
simple functionality in my wrapper to keep the coupling loose or
wrapping more of what NHibernate in order to take advantage of what it
offers but at the loss of loose coupling.
From: Matt Lund [mailto:ml...@control4.com]
Sent: Saturday, July 18, 2009 3:20 PM
To: Log4NET User
Subject: RE: Wrapping Log4Net
This reminds me of my attempt to wrap our use of NHibernate. I later
realized this was a bad idea for a practical reason and philosophical
reason. The practical challenge was that I had to choose between only
exposing simple functionality in my wrapper to keep the coupling loose.
The philosophical epiphany we later had was that there is a difference
between services and frameworks. Loosely coupling your program to
services is usually a good idea. Loosely coupling your program to
frameworks is usually a bad idea.
In short, I'd reconsider wrapping it.
From: Peter Drier [mailto:peter.dr...@gmail.com]
Sent: Saturday, July 18, 2009 3:10 PM
To: Log4NET User
Subject: Re: Wrapping Log4Net
Because of A, wrapping log4net is a bad idea. It's a noble thought,
but in 10+ years of using log4net and having people around and above me
demand wrapping, I've never seen log4net replaced. Given you can
always write an appender to output to any other system as necessary, the
need for wrapping is moot.
B) the only way to wrap it better would be to walk the stack
everytime something is logged to see who the calling method was..
Horribly slow, so I wouldn't call it better.
C) Some part of your config is wrong. We log in release mode all the
time.
-Peter
On Sat, Jul 18, 2009 at 4:53 PM, xalex a...@pixafe.com wrote:
Hi forum,
I would like to use log4net in a large .net development. because i have
the
requirement to prepare a potential replacement of the log4net framework
e.g.
against ms-enterprise library or against a newer version of log4net, i
would
like to wrap this. My way to do it is straight forward:
A single assembly references the log4net framework, offes the ILog and
LogManager classes, and all other projects reference only this wrapper
(see
below).
This wrapper allows me to restrict the users on only the main functions
which are really needed and allows me to replace this framework,
potentially.
Now my question: When the ILog.Debug() Method is called, the output in
the
logfile is wrong, because the LocationInfo used for this output
corresponds
to the Wrapper and not to the code from which it is really called :-(
A: Is there an easy way to fix this problem?
B: Is there a better idea to wrap log4net
C: Is it true, that logging is only possible in DEBUG-Builds? When using
the
release build, i dont get any output
Thanks
Alex
Wrapper:
public interface ILog
{
bool IsDebugEnabled { get; }
bool IsErrorEnabled { get; }
bool IsFatalEnabled { get; }
bool IsInfoEnabled { get; }
bool IsWarnEnabled { get; }
void Debug(object message);
void Error(object message);
void Fatal(object message);
void Info(object message);
void Warn(object message);
}
public static class LogManager
{
static LogManager()
{
XmlConfigurator.Configure( new
System.IO.FileInfo(c:/logger.xml)) ;
}
public static ILog GetLogger(Type type)
{
MyLog log = new MyLog(log4net.LogManager.GetLogger(type) );
return log;
}
}
public class MyLog :ILog
{
private log4net.ILog _log;
public MyLog(log4net.ILog log)
{
_log = log;
}
#region ILog Members
public bool IsDebugEnabled
{
get { return _log.IsDebugEnabled; }
}
public void Debug(object message)
{
_log.Debug(message);
}
...
}
--
View this message in context:
http://www.nabble.com/Wrapping-Log4Net-tp24551728p24551728.html
Sent from the Log4net - Users mailing list archive at Nabble.com.
RE: Using thread context data from a filter to decide whether to append...
Bump J Hoping for some feedback... From: Matt Lund [mailto:ml...@control4.com] Sent: Thursday, June 11, 2009 11:16 AM To: log4net-user@logging.apache.org Subject: Using thread context data from a filter to decide whether to append... Hi all. I'd like to know if I'm doing this correctly. I want to set a value in ThreadContext.Properties from application code. I then want some appenders to log or not log based on this contextual information. I believe the right way to do this is to create a class that implements IFilter and apply some filters to the these appenders. So far I've created my filter class, and I've added the ThreadContext.Properties[foo] = bar to my application code. Now, I'm looking at how to implement the Decide method on my filter class. I had assumed that the foo-bar information would be available in the LoggingEvent that gets passed in to Decide but if it's there, I don't see it. However, if I directly access ThreadContext.Properties[foo] from inside the Decide method then that works. This seemed odd to me at first because I didn't know that Decide() would always be called on the thread where the log.Info(etc) call came from. But if Decide() is always called on that thread, I should be safe to access ThreadContext.Properties[foo] from inside Decide() - right? If I'm not correct or there's a better way to access the thread-contextual information from inside Decide() please let me know...
RE: Using AdoNetAppender
Have you already gotten AdoNetAppender to work from a app.config /
web.config first? If not, I'd suggest getting that to work first. You
may learn something in that process and it'll spark a realization of
what you're missing in the from-code approach?
-Original Message-
From: James Green [mailto:james.gr...@occam-dm.com]
Sent: Monday, June 15, 2009 9:26 AM
To: Log4NET User
Subject: Using AdoNetAppender
Hi All,
I've spent about 4 hours today trying to get this working and have
totally failed so far.
I can't even really find much info on how to configure this purely in
Code. In fact there is precious little I can find on the net in fact.
Here is the code I'm using the set up the AdoNetAppender in my app:
public static void ConfigureDatabaseAppender(string connString)
{
PatternLayout layout = GetDefaultLayout();
_sqlDatabaseAppender = new AdoNetAppender();
_sqlDatabaseAppender.Layout = layout;
_sqlDatabaseAppender.UseTransactions = false;
_sqlDatabaseAppender.BufferSize = 1;
_sqlDatabaseAppender.CommandType = System.Data.CommandType.Text;
_sqlDatabaseAppender.ConnectionString = connString;
_sqlDatabaseAppender.CommandText = INSERT INTO Log
([Date],[Level],[Thread],[Logger],[Message],[Exception]) VALUES
(@log_date, @log_level, @thread, @logger, @message, @exception);
AdoNetAppenderParameter logDate = new AdoNetAppenderParameter();
RawTimeStampLayout dateLayout = new RawTimeStampLayout();
logDate.ParameterName = @log_date;
logDate.Layout = dateLayout;
logDate.DbType = System.Data.DbType.DateTime;
_sqlDatabaseAppender.AddParameter(logDate);
AdoNetAppenderParameter logThread = new AdoNetAppenderParameter();
logThread.ParameterName = @thread;
logThread.Size = 255;
logThread.DbType = System.Data.DbType.String;
_sqlDatabaseAppender.AddParameter(logThread);
AdoNetAppenderParameter logLevel = new AdoNetAppenderParameter();
logLevel.ParameterName = @log_level;
logLevel.Size = 50;
logLevel.DbType = System.Data.DbType.String;
_sqlDatabaseAppender.AddParameter(logLevel);
AdoNetAppenderParameter logLogger = new AdoNetAppenderParameter();
logLogger.ParameterName = @logger;
logLogger.Size = 255;
logLogger.DbType = System.Data.DbType.String;
_sqlDatabaseAppender.AddParameter(logLogger);
AdoNetAppenderParameter logMessage = new AdoNetAppenderParameter();
logMessage.ParameterName = @message;
logMessage.Size = 4000;
logMessage.DbType = System.Data.DbType.String;
_sqlDatabaseAppender.AddParameter(logMessage);
AdoNetAppenderParameter logException = new AdoNetAppenderParameter();
logException.ParameterName = @exception;
logException.Size = 2000;
logException.DbType = System.Data.DbType.String;
_sqlDatabaseAppender.AddParameter(logException);
_sqlDatabaseAppender.ActivateOptions();
BasicConfigurator.Configure(_sqlDatabaseAppender);
}
Any help would be great.
James.
Using thread context data from a filter to decide whether to append...
Hi all. I'd like to know if I'm doing this correctly. I want to set a value in ThreadContext.Properties from application code. I then want some appenders to log or not log based on this contextual information. I believe the right way to do this is to create a class that implements IFilter and apply some filters to the these appenders. So far I've created my filter class, and I've added the ThreadContext.Properties[foo] = bar to my application code. Now, I'm looking at how to implement the Decide method on my filter class. I had assumed that the foo-bar information would be available in the LoggingEvent that gets passed in to Decide but if it's there, I don't see it. However, if I directly access ThreadContext.Properties[foo] from inside the Decide method then that works. This seemed odd to me at first because I didn't know that Decide() would always be called on the thread where the log.Info(etc) call came from. But if Decide() is always called on that thread, I should be safe to access ThreadContext.Properties[foo] from inside Decide() - right? If I'm not correct or there's a better way to access the thread-contextual information from inside Decide() please let me know...
