Проблема с определенным именем логгера NLog - PullRequest
Новая
       43

Проблема с определенным именем логгера NLog

3 голосов
/ 16 октября 2010

У меня есть два правила, настроенные в NLog.config: 

<logger name="Model" level="Info" writeTo="modelLog" final="true" />
<logger name="*" minlevel="Debug" writeTo="logFile" />

Я пытаюсь написать первый, используя следующий код: 

LogEventInfo eventInfo = new LogEventInfo();
eventInfo.Level = LogLevel.Info;
eventInfo.LoggerName = "Model";
eventInfo.TimeStamp = DateTime.Now;
logger.Log(eventInfo);

Но оно продолжает падать на второе правило. Я бы подумал, eventInfo.LoggerName = "Model"; послал бы это прямо к первому правилу?

1 Ответ

3 голосов
/ 16 октября 2010

Сейчас не за компьютером, поэтому не могу попробовать ваше дело, но у меня есть пара вопросов.

  1. Можете ли вы попробовать использовать "обычные" функции ведения журнала (Info, Debug) и посмотреть, работает ли это, как ожидается?

  2. Как вы решили свой логгер? То есть. Что такое имя "регистратора"?

Если имя реального регистратора не «Модель», я предполагаю, что оно не будет соответствовать условию «Модель», даже если вы передаете «Модель» в поле «Имя» в LogEventInfo.

[EDIT] Вот сокращенный пример лучшей оболочки журнала NLog, которую можно использовать в расширении Ninject Logging. Эта оболочка делегирует протоколирование вызовов в базовый регистратор NLog таким образом, чтобы сохранить информацию о сайте вызовов (класс и метод, из которого возник запрос на регистрацию). 

  class NLogLogger : ILogger
  {
    private NLog.Logger logger;

    //The Type that is passed in is ultimately the type of the current object that
    //Ninject is creating.  In the case of my example, it is Class1 and Class1 is
    //dependent on ILogger.
    public NLogLogger(Type t)
    {
      logger = NLog.LogManager.GetLogger(t.FullName);
    }

    //Trace, Warn, Error, Fatal eliminated for brevity

    public bool IsInfoEnabled
    {
      get { return logger.IsInfoEnabled; }
    }

    public bool IsDebugEnabled
    {
      get { return logger.IsDebugEnabled; }
    }

    public void Info(string format, params object [] args)
    {
      if (logger.IsInfoEnabled)
      {
        Write(LogLevel.Info, format, args);
      }
    }

    public void Debug(string format, params object [] args)
    {
      if (logger.IsDebugEnabled)
      {
        Write(LogLevel.Debug, format, args);
      }
    }

    private void Write(LogLevel level, string format, params object [] args)
    {
      LogEventInfo le = new LogEventInfo(level, logger.Name, null, format, args);
      logger.Log(typeof(NLogLogger), le);
    }
  }

Очевидно, что этот пример не касается исключений. Тем не менее, я думаю, что это иллюстрирует правильный способ упаковки NLog. Было бы достаточно легко реализовать полный интерфейс ILogger расширения Ninject Logging, делегируя каждый вызов Info, Debug, Warn и т. Д. Центральному методу Write, который будет создавать класс LogEventInfo, а затем регистрировать его с помощью базового экземпляра регистратора NLog, передав тип регистратора упаковки (typeof(NLogLogger) в моем примере). Передача типа регистратора упаковки имеет решающее значение для ведения информации о сайте вызовов для регистрации вызовов из кода вашего приложения.

На основе оболочки NLog, найденной в git-репозитории Ninject Logging Extensions .

Подробнее о внедрении зависимостей и именованных регистраторах (например, NLog и log4net).

См. Мой ответ здесь , чтобы узнать больше о проблемах с простейшими упаковщиками логгера.

...