While it might boost efficiency slightly, it seems like a bad idea to depend
on the logging layer for core functionality. Given your requirement and
concern for efficiency, I would write my own (or maybe pilfer L4N's)
watching code, then reconfigure L4N from my code. The separation of
concerns is
I don't think the problem was really the MinimalLock at all (ultimately).
For instance, I can view a log file in Notepad, and it will continue to be
updated, without using MinimalLock (confirm this for yourself).
The problem is how you are opening the file. I believe the StreamReader
constructor
Title: Message
From the .NET
SDK:
GetHashCode
provides identification for managed threads. For the lifetime of your thread, it
will not collide with the value from any other thread, regardless of the
application domain from which you obtain the value.
Note An operating-system ThreadI
Title: Message
More
generally, if your components are prone to "hanging," this seems like a larger
problem than a logging issue. You may want to design the observer app to
watch the components themselves, then start alerting as soon as the hang
occurs.
-Marc
-Original Message---
Just a thought, since it seems like what you are attempting is a real-time
logging scenario, why not use a different appender more suited to the task?
You could retain the rolling-file appender, but for the RichTextBox you
could display the contents of a console appender (if it is in the same
proce
You've got it right. That is my experience as well.
-Marc
-Original Message-
From: Sam Smoot [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 21, 2005 8:44 PM
To: Log4NET User
Subject: Re: line numbers of exceptions no longer show
Don't line numbers only show in debug builds? Without t
See
http://logging.apache.org/log4net/release/manual/faq.html#HC-14456678.
This is nothing to get upset about. Really, we're talking about doing
the same thing two different ways. Log4net's approach is minimal,
Nlog's is maximal. The minimal approach requires more code to call, but
allows for a
Nicko,
Just for clarity, though: if a logger has two appenders and one fails,
the logger will continue logging to the "remaining" appender?
-Marc
-Original Message-
From: Nicko Cadell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 16, 2004 2:39 PM
To: Log4NET User
Subject: RE: can on
Title: Message
On a previous thread
the issue of log4net's fitness-of-purpose for more mission-critical logging came
up. As you may know, log4net makes no claim to reliability, only to being
a fail-stop (near-silent fail) logging system.
Nonetheless, it is a
very clean, usable, and easily
Title: Message
Benjamin,
One
other thing: log4net's failure isn't necessarily silent. If there is a
configuration error or some other issue that stops log4net from logging, it
writes a single message to System.Console.Error (see same link as
previous).
-Marc
-Original Message-
Title: Message
Benjamin,
Actually, the uses you envision, while they would be really great to have
in a product as flexible as log4net, would be outside the intended uses of the
product. Not that you can't, just that you do so at your own risk.
See http://logging.apache.org/log4net/releas
Title: Message
Ayende,
Check
out the SDK docs under "PatternLayout class".
-Marc
-Original Message-From: Ayende Rahien
[mailto:[EMAIL PROTECTED] Sent: Friday, October 08, 2004 4:45
PMTo: 'Log4NET User'Subject: ConversionPattern for
PatternLayout
Where can I get t
12 matches
Mail list logo
