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 "Andras Nemes (JIRA)" <ji...@apache.org> on 2016/06/29 08:17:34 UTC

[jira] [Created] (LOG4NET-520) MessageObject property of LoggingEvent not populated if using constructor with LoggingEventData

Andras Nemes created LOG4NET-520:
------------------------------------

             Summary: MessageObject property of LoggingEvent not populated if using constructor with LoggingEventData
                 Key: LOG4NET-520
                 URL: https://issues.apache.org/jira/browse/LOG4NET-520
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
            Reporter: Andras Nemes


If I use the constructor...

public LoggingEvent(Type callerStackBoundaryDeclaringType, log4net.Repository.ILoggerRepository repository, string loggerName, Level level, object message, Exception exception)

...to build a LoggingEvent object then the private field m_message will be populated with the incoming "message" parameter. The result is that both the MessageObject and the RenderedMessage property of LoggingEvent will have the correct message value.

However, if I use the following constructor...

public LoggingEvent(LoggingEventData data)

...where I populate the Message field of the LoggingEventData struct with some message then the m_message private field is not populated at all, it remains null. Therefore the MessageObject property of LoggingEvent will also be null. However, RenderedMessage will still have the correct value.

This causes an issue with at least one appender: gelf4net (https://github.com/jjchiw/gelf4net) which relies on the MessageObject property.

Regardless of gelf4net, I think it makes sense to populate as many private fields of LoggingEvent as possible using LoggingEventData, including m_message.

Reference:
http://svn.apache.org/viewvc/logging/log4net/trunk/src/Core/LoggingEvent.cs?revision=1707180&view=markup

Thanks for your help,
Andras Nemes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)