Logging classes supported inside a log4net appender?

Question

I would like to build an appender that sends all messages to a central tcp server. However, the messaging framework i would like to use for this uses log4net logger instances itself to support debugging / tracing. Thus it would seem problematic to activate a debug log protocolizing all messages that are about to be send, as this debug message itself would create another message of the same type.

Is there a log4net protection to prevent name of this web site situations?

Answer 1

From what I understood: you are using a class or framework inside your custom appender which is by itself using log4net to write logs and you want to avoid looping when transferring those logs through your appender.

I can think of two ways that can help you avoid that:

• Using LogLog mechanism
• Filtering the messages coming from your framework

---

Using LogLog

Only if you have access to your framework code:

You can change the code that it will get by configuration whether to use log4net regular logger or LogLog logger.

Logging through LogLog is done like that:

log4net.Util.LogLog.Error(this.GetType(), "your error here");

Use this link to read more about LogLog.
Use this link to read how to enable LogLog while running.

---

Filtering messages

If your framework has unique logger name you can configure that it's logs will not be transferred through your custom appender.

Either by closing it's completely:

<logger name="Framework.logger.name">
    <level value="OFF" />
</logger>

Or by transferring only specific loggers through your custom appender

<logger name="specific.logger.name">
    <level value="ALL" />
    <appender-ref ref="MyCustomAppender" />
</logger>

You can read more here .

Answer 2

Did you write the messaging framework your self? If it is true that when there is a trace massage, the framework keeps adding trace messages, it would not be very useful, even if you are not using log4net yourself. I guess the framework will not add trace messages that trigger it self. The only way you know is test the framework and see if it is working. Or post the code that creates the loop.