You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Ron Grabowski (JIRA)" <ji...@apache.org> on 2013/06/10 05:27:21 UTC

[jira] [Comment Edited] (LOG4NET-342) Add a way to prevent silent failure

    [ https://issues.apache.org/jira/browse/LOG4NET-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679278#comment-13679278 ] 

Ron Grabowski edited comment on LOG4NET-342 at 6/10/13 3:26 AM:
----------------------------------------------------------------

ILog is the main interface for generating log messages. Shouldn't it stay focused on being an infrequently changing interface that is the entry point for sending messages into the system? As you pointed out the repository already knows if its configured:

  LogManager.GetRepository().Configured

What's the next step for the user when Configured==false? This is possible today...little bit yucky because ConfigurationMessages is ICollection:

  var configErrorMessages = LogManager.GetRepository().ConfigurationMessages.Cast<LogLog>()
    .Where(x => x.Prefix.Contains("ERROR"))
    .Select(x => x.Message);

I think effort should be put into upgrading ConfigurationMessages from ICollection to something that is more friendly for when Configured==false.

If your repository contains appenders that follow the pattern of extending AppenderSkeleton and using OnlyOnceErrorHandler you might be able to get away with this if you're wanting to monitor things like file system permission/locking issues:

  // untested
  foreach (var appender in LogManager.GetRepository().GetAppenders())
  {
      var skeleton = appender as AppenderSkeleton;
      if (skeleton != null)
      {
          var onlyOnce = skeleton.ErrorHandler as OnlyOnceErrorHandler;
          if (onlyOnce != null && onlyOnce.IsEnabled)
          {
              Console.WriteLine("{0}: {1}", appender.Name, onlyOnce.ErrorMessage);
          }
      }
  }
                
      was (Author: ron):
    ILog is the main interface for generating log messages. Shouldn't it stay focused on being an infrequently changing interface that is the entry point for sending messages into the system? As you pointed out the repository already knows if its configured:

{code}
LogManager.GetRepository().Configured
{code}

What's the next step for the user when Configured==false? This is possible today...little bit yucky because ConfigurationMessages is ICollection:

{code}
var configErrorMessages = LogManager.GetRepository().ConfigurationMessages.Cast<LogLog>()
  .Where(x => x.Prefix.Contains("ERROR"))
  .Select(x => x.Message);
{code}

I think effort should be put into upgrading ConfigurationMessages from ICollection to something that is more friendly for when Configured==false.

If your repository contains appenders that follow the pattern of extending AppenderSkeleton and using OnlyOnceErrorHandler you might be able to get away with this if you're wanting to monitor things like file system permission/locking issues:

{code}
// untested
foreach (var appender in LogManager.GetRepository().GetAppenders())
{
    var skeleton = appender as AppenderSkeleton;
    if (skeleton != null)
    {
        var onlyOnce = skeleton.ErrorHandler as OnlyOnceErrorHandler;
        if (onlyOnce != null && onlyOnce.IsEnabled)
        {
            Console.WriteLine("{0}: {1}", appender.Name, onlyOnce.ErrorMessage);
        }
    }
}
{code}
                  
> Add a way to prevent silent failure
> -----------------------------------
>
>                 Key: LOG4NET-342
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-342
>             Project: Log4net
>          Issue Type: New Feature
>            Reporter: Joachim Zobel
>            Assignee: Dominik Psenner
>            Priority: Minor
>             Fix For: 1.2.12
>
>
> I spent most of the day trying to find out why logging is not working on my dev system but not on test. There should be a way to force error reporting by throwing (possibly unhandled) exceptions. This could be done by adding a required flag to the appenders and another flag that requires a least one working appender.
> I am not sure about a good way to implement this, I would just love it if my favourite tool to end silent failure could stop failing silently. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira