Mailing-List: contact log4net-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4NET Dev" <log4net-dev@logging.apache.org>
Received-SPF: pass (athena.apache.org: domain of dpsenner@gmail.com designates
 74.125.83.47 as permitted sender)
From: "Dominik Psenner" <dpsenner@gmail.com>
To: "'Log4NET Dev'" <log4net-dev@logging.apache.org>
References: <34508400.post@talk.nabble.com>
 <F03521996DA54232BBC2CE65FD90B249@alpin.local>
 <34508605.post@talk.nabble.com>
In-Reply-To: <34508605.post@talk.nabble.com>
Subject: RE: Object Reference issue in changing the Log file name dynamically
 in threads
Date: Wed, 3 Oct 2012 14:06:53 +0200
Message-ID: <992368533831410DB77AF537D4EE5965@alpin.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac2hWMizG5TZVTp+QF6pwJtG9mrBQQAAcB6g
x-ms-exchange-organization-originalclientipaddress: 192.168.25.115
x-ms-exchange-organization-originalserveripaddress: fe80::dbc:9157:39b:6c99%12
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609
X-Virus-Checked: Checked by ClamAV on apache.org

>This Works fine

Glad to hear that.

>.. i am unable to use static appenders. Because i need to
>change the name of the log file based on my processing function in my
>application.

I can understand your problem. Unfortunately there is no easy way to change
the logfile dynamically at runtime. It all comes down to spawning and
disposal of file appenders at runtime.

>Now my problem is am unable to use httpcontext or session
>objects in threads.. Is there any way to do this?

Log4net does not imply rules on the scope of httpcontext or session
variables in threads. Thus this does not seem to be a log4net problem at
all. If I did not understand what you were saying here, please rephrase the
question.

>Or else how can i creating log files dynamically?

In my opinion there's no safe way to do that. But someone elses mileage may
vary. A logfile is equivalent to a single (rolling) file appender and a
single (rolling) file appender can only append log events into exactly one
logfile. If you somehow manage to change that logfile at runtime it will
affect all other log events that should be written by this (rolling) file
appender too. Whether or not they come from another thread doesn't matter.

Generally said, the "logic" of dispatching messages should be placed into
event filters that are assigned to an appender. You could create a hierarchy
of remoting appenders that finally sink log events into a rolling file
appender, but in my humble opinion this construct is far to complex for a
mere logger. The worst logger you can have is one that does not log at all
because it was designed too complicated.

Therefore I encourage you to log events into a database. Then you can fetch
log events from that database with all different fancy logic you need.

Cheers,
D.