Thank you Nicko.
I have succesfully used DebugView and catched 
Log4net messages at application startup.
 
Particularly, log4net cannot access web.config
[System.UnauthorizedAccessException: Access to the path ... is denied]
 
Since at least one other application (that runs under the same
account, with exactly the same privileges) on the same 
server does read it and initialize correctly, I suspect
the problem lays in the cluster setup.
 
I will further investigate the problem with our sysadmins.
 
a.
 
 

________________________________

From: Nicko Cadell [mailto:[EMAIL PROTECTED]
Sent: Sun 9/26/2004 8:34 PM
To: Log4NET User
Subject: RE: Logging on network share



Alberto,

If you can enable log4net internal debugging you should get details of
any errors that log4net encounters.
See
http://logging.apache.org/log4net/release/manual/faq.html#internalDebug
from more details.

Cheers,
Nicko

> -----Original Message-----
> From: Alberto Bolchini [mailto:[EMAIL PROTECTED]
> Sent: 21 September 2004 17:15
> To: [email protected]
> Subject: Logging on network share
>
> Hello.
> 
> We are having a bizarre behaviour on logging in this environment:
> 
> - log4net 1.2.0 Beta 8 (07/15)
> - .Net Framework 1.1
> - 2 load-balanced, clusterd web servers, with 4 web
> applications (each) mounting their docroot from a network share.
> 
> On both servers, Runtime Security Policies have been modified
> to let the assemblies get loaded from the network share (new
> Code groups have been created at Machine level, , and all the
> application start-up successfully. Nevertheless, just 3
> applications out of 8 log anything using the
> RollingFileAppender; the odd thing is that one app. logs from
> both the servers and one of the other apps logs from just one server.
> 
> Configurations (web.config stanzas for log4net) are all the
> same except for the filename where the appender should log
> (this is located on the network share as well).
> 
> Does anybody have suggestions on directions to take to
> investigate the problem?
> 
> Thanks
> 
> Alberto.
> 
>


<<winmail.dat>>

Reply via email to