Julie Sheffield (JIRA | 18 Sep 02:14 2010
Picon

[jira] Issue Comment Edited: (LOG4NET-1) Support Fallback Appenders


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

Julie Sheffield edited comment on LOG4NET-1 at 9/17/10 8:13 PM:
----------------------------------------------------------------

I implemented this behavior for the RemotingAppender by having it implement IAppenderAttachable
(exactly the way ForwardingAppender implements it).  Then I could add the backup appender just by
specifying appender-ref in log4net.config.  Then in the catch block, before calling
ErrorHandler.Error(message, ex), I look to see if any appenders have been attached and forward the
LoggingEvent to them.

Of course, this approach is specific only to the RemotingAppender.  Since that's what I need for the project
I'm working on, that's what I've tested extensively, but it seems like it wouldn't be hard to take a similar
approach with other potentially error-prone appenders like ADONetAppender if it's too disruptive to
change the entire IErrorHandler interface.

In the meantime, should I check in my changes to RemotingAppender?  Seems like that one is particularly
susceptible to potential intermittent interruptions and other HA applications might need similar
behavior to what I've implemented and tested.  Where should I upload my code so people could take a look and
see if it's worth including?

Thanks!

      was (Author: codegrll):
    I implemented this behavior for the RemotingAppender by having it implement IAppenderAttachable
(exactly the way ForwardingAppender implements it).  Then I could add the backup appender just by
specifying appender-ref in log4net.config.  Then all I needed to do was in the catch block , before calling
ErrorHandler.Error(message, ex), I look to see if any appenders have been attached and forward the
LoggingEvent to them.

Of course, this approach is specific only to the RemotingAppender.  Since that's what I need for the project
I'm working on, that's what I've tested extensively, but it seems like it wouldn't be hard to take a similar
approach with other potentially error-prone appenders like ADONetAppender if it's too disruptive to
change the entire IErrorHandler interface.

In the meantime, should I check in my changes to RemotingAppender?  Seems like that one is particularly
susceptible to potential intermittent interruptions and other HA applications might need similar
behavior to what I've implemented and tested.  Where should I upload my code so people could take a look and
see if it's worth including?

Thanks!

> Support Fallback Appenders
> --------------------------
>
>                 Key: LOG4NET-1
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-1
>             Project: Log4net
>          Issue Type: New Feature
>          Components: Appenders, Core
>    Affects Versions: 1.2.9
>         Environment: From sourceforge
>            Reporter: Nicko Cadell
>             Fix For: v.Next
>
>         Attachments: RemotingAppender.cs
>
>
> Basically, I'm looking for the ability to set up a hierarchy of appenders so that if a log to an
ADONETAppender fails, log4net could then log to one of more "back-up" appenders, for example, a
RollingLogFile or SMTP.
> Thanks,
> Leo
> Leo J. Hart IV

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Gmane