You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-user@logging.apache.org by unegov <un...@skbkontur.ru> on 2006/04/03 06:56:46 UTC
Re[4]: Logging of the errors in logging
Yes, I could but error messages and debug messages are not separated
in the Trace: log4net uses Trace.WriteLine for both. In my case I
would prefer the executing code to be interrupted if the error
occured. And when I'm talking about it I don't mean that log4net has
to be a reliable logging system. I could also intercept Console.Error
but logging error messages are written to Console.Error in one or two
steps: extra error message and then exception description or error
message alone. It is not convenient to see only extra message after
code execution was interrupted. By the way it would be a pure
workaround, not the regular usage of the log4net.
RG> Your application can process messages written to
RG> System.Diagnostic.Trace by using code like this in your App.Config:
RG> <system.diagnostics>
RG> <trace autoflush="true">
RG> <listeners>
RG> <add name="textWriterTraceListener"
RG> type="System.Diagnostics.TextWriterTraceListener"
RG> initializeData="C:\\Company\\Application\\Logs\\log4net.txt" />
RG> </listeners>
RG> </trace>
RG> </system.diagnostics>
RG> You can also configure that in code.
RG> --- unegov <un...@skbkontur.ru> wrote:
>> Ok. But nevertheless log4net propagates logging problems into
>> Console.Error and into Trace. Can I expect that in the near or
>> distant
>> future log4net will allow me to override this behaviour?
>> I think it would not contradict the ideology of log4net as a best
>> effort logging system. It would just give me chance to change the way
>> I monitor problems with logging.
>>
>> Thanks.
>>
>> Best regards,
>> Stepan Unegov.
>>
>> NC> Log4net is designed to be a best effort logging system, not a
>> reliable
>> NC> system. If there is a problem logging log4net will not propagate
>> errors
>> NC> into the calling application.
>> NC> While the current internal error handling is not flexible enough
>> it is
>> NC> unlikely that it will be changed to accommodate a completely
>> reliable
>> NC> logging scenario.
>>
>> NC> Regards,
>> NC> Nicko
>>
>> >> -----Original Message-----
>> >> From: unegov [mailto:unegov@skbkontur.ru]
>> >> Sent: 30 March 2006 08:43
>> >> To: log4net-user@logging.apache.org
>> >> Subject: Logging of the errors in logging
>> >>
>> >> Log4net is a great tool but I'm not fully satisfied how
>> >> log4net deals with errors in logging. In my project it is
>> >> necessary not to lose any logging messages if the logging is
>> >> on so I would prefer log4net threw exceptions rather than
>> >> wrote errors of logging into Console.Error and Trace as
>> >> information messages. I'm ready to catch such sort of
>> >> exceptions at the top level of my code. But I have no way to
>> >> override the behaviour of the LogLog class.
>> >>
>> >> All I can do is to intercept Console.Error and rethrow
>> >> exceptions in the interception code but in this case I wont
>> >> always get complete exception messages and it doesnt look
>> >> beautiful at all.
>> >>
>> >> Another way is to rebuild log4net but I will get a lot of
>> >> problems with other projects (nhibernate) which references
>> >> native assembly of the log4net. So the question: is it
>> >> possible to add to log4net different strategies of managing
>> >> errors in logging? Is there any other way to cope with the
>> problem?
>> >>
>> >> ErrorHandlers used in appenders don't cover all possible errors.
>> I.e.
>> >> if some error in configuring occures it is most likely that
>> >> no appender will be added to logger.
>> >>
>> >> Thanks.
>> >>
>> >> Best regards,
>> >> Stepan Unegov.
>> >>
>> >>
>> >>
>>
>>
--
Best regards,
unegov mailto:unegov@skbkontur.ru
Re: Re[4]: Logging of the errors in logging
Posted by Ron Grabowski <ro...@yahoo.com>.
If we changed ILoggerRepository to add an ConfigurationMessageEvent
event:
public interface ILoggerRepository
{
// snip
event LoggerRepositoryConfigurationMessageEventHandler
ConfigurationMessageEvent;
}
someone could write an IPlugin that inspected the message to determine
if it were an error-config-message or just a debug-config-message. This
plugin would have to have some sort of marking to indicate it should be
initialized a single time during the application's lifecycle (so its
not reloaded when the repository reloads). If the message were an
error, the plugin could throw an exception immediately (this would
satisfy the people who want log4net to throw configuration exceptions),
queue up the exceptions and throw a single exception at the end, or
store the error messages and warnings and let the user deal with them
accordingly.
A super advanced configuration-IPlugin might be able to create its own
internal ILoggerRepository with a pre-determined set of appenders to
report configuration errors from the main ILoggerRepository. In other
words, if I encountered any errors while setting up log4net I could use
a special plugin to report the errors via a AdoNetAppender or a
EventLogAppender without issuing Trace messages or writing to the
Console.
I don't know how much of that is really possible or practical. There's
a good chance I don't fully understand the relationship and loading
order of an ILoggerRepository and an IPlugin. Here's a good post from
Nikco recapping the current state of Plugins:
http://tinyurl.com/jadcc
--- unegov <un...@skbkontur.ru> wrote:
> Yes, I could but error messages and debug messages are not separated
> in the Trace: log4net uses Trace.WriteLine for both. In my case I
> would prefer the executing code to be interrupted if the error
> occured. And when I'm talking about it I don't mean that log4net has
> to be a reliable logging system. I could also intercept Console.Error
> but logging error messages are written to Console.Error in one or two
> steps: extra error message and then exception description or error
> message alone. It is not convenient to see only extra message after
> code execution was interrupted. By the way it would be a pure
> workaround, not the regular usage of the log4net.
>
> RG> Your application can process messages written to
> RG> System.Diagnostic.Trace by using code like this in your
> App.Config:
>
> RG> <system.diagnostics>
> RG> <trace autoflush="true">
> RG> <listeners>
> RG> <add name="textWriterTraceListener"
> RG> type="System.Diagnostics.TextWriterTraceListener"
> RG> initializeData="C:\\Company\\Application\\Logs\\log4net.txt"
> />
> RG> </listeners>
> RG> </trace>
> RG> </system.diagnostics>
>
> RG> You can also configure that in code.
>
> RG> --- unegov <un...@skbkontur.ru> wrote:
>
> >> Ok. But nevertheless log4net propagates logging problems into
> >> Console.Error and into Trace. Can I expect that in the near or
> >> distant
> >> future log4net will allow me to override this behaviour?
> >> I think it would not contradict the ideology of log4net as a best
> >> effort logging system. It would just give me chance to change the
> way
> >> I monitor problems with logging.
> >>
> >> Thanks.
> >>
> >> Best regards,
> >> Stepan Unegov.
> >>
> >> NC> Log4net is designed to be a best effort logging system, not a
> >> reliable
> >> NC> system. If there is a problem logging log4net will not
> propagate
> >> errors
> >> NC> into the calling application.
> >> NC> While the current internal error handling is not flexible
> enough
> >> it is
> >> NC> unlikely that it will be changed to accommodate a completely
> >> reliable
> >> NC> logging scenario.
> >>
> >> NC> Regards,
> >> NC> Nicko
> >>
> >> >> -----Original Message-----
> >> >> From: unegov [mailto:unegov@skbkontur.ru]
> >> >> Sent: 30 March 2006 08:43
> >> >> To: log4net-user@logging.apache.org
> >> >> Subject: Logging of the errors in logging
> >> >>
> >> >> Log4net is a great tool but I'm not fully satisfied how
> >> >> log4net deals with errors in logging. In my project it is
> >> >> necessary not to lose any logging messages if the logging is
> >> >> on so I would prefer log4net threw exceptions rather than
> >> >> wrote errors of logging into Console.Error and Trace as
> >> >> information messages. I'm ready to catch such sort of
> >> >> exceptions at the top level of my code. But I have no way to
> >> >> override the behaviour of the LogLog class.
> >> >>
> >> >> All I can do is to intercept Console.Error and rethrow
> >> >> exceptions in the interception code but in this case I wont
> >> >> always get complete exception messages and it doesnt look
> >> >> beautiful at all.
> >> >>
> >> >> Another way is to rebuild log4net but I will get a lot of
> >> >> problems with other projects (nhibernate) which references
> >> >> native assembly of the log4net. So the question: is it
> >> >> possible to add to log4net different strategies of managing
> >> >> errors in logging? Is there any other way to cope with the
> >> problem?
> >> >>
> >> >> ErrorHandlers used in appenders don't cover all possible
> errors.
> >> I.e.
> >> >> if some error in configuring occures it is most likely that
> >> >> no appender will be added to logger.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> Best regards,
> >> >> Stepan Unegov.
> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
>
> --
> Best regards,
> unegov mailto:unegov@skbkontur.ru
>
>