Manik/Ceki,
I haven't followed this conversation in depth so ignore me
if my comments are obviously out of place. However, it is
important to realize that if an appender fails once or even
many times the user may still want it attached. For example
a JDBCAppender may fail due to a network problem during
which the message might go to a file, but once the network
problem is resolved the user may want the logging to go back
to the JDBCAppender (or both). If I have a critical system
with a momentary hiccup, I don't want to restart the app to
get logging back to the desired location, though I certainly
do want a fail-over-backup location.
Kevin
Ceki Gülcü wrote:
>
> Hi Manik,
>
> At 14:38 14.11.2001 +0000, you wrote:
> ?Hi, Ceki.
> ?
> ?I have written a FallbackErrorHandler, looking at the code of the
>OnceOnlyErrorHandler class and the Appender interface. I have attached what I have
>done so far, but I do need a bit of help in a few areas, notably:
> ?
> ?1) How can I initialise/kick off an appender? And how do I set it so that new
>calls made via Category.debug(), etc. go to this new appender?
>
> You can attach/remove appenders to a category using the Category
>addAppender/removeAppender methods.
>
> ?2) How do I programatically write a log directly to an appender without using the
>Category class? I use this to log to the new appender that the old one has died and
>a new one has taken over.
>
> If you remove the old failing appender from the relevant category and add a new
>appender to it, then you are done, right?
>
> Unfortunately, the error methods in the ErrorHandler interface do not pass a
>reference to the failing appender (so that you can remove it). So we would need to
>change the interface as follows:
>
> public interface ErrorHandler extends OptionHandler {
> void error(Appender failingAppender, String message, Exception e, int errorCode);
> void error(Appender failingAppender, String message);
> }
>
> This in turn would require that we modify the error handler invocations in all
>appenders. This would also break backward compatibility with existing appenders
>written by our users outside the log4j distribution. To preserve backward
>compatibility we need:
>
> public interface ErrorHandler extends OptionHandler {
>
> /**
> @deprecated Please use the equivalent error method which takes an Appender
> as its first parameter.
> */
> void error(String message, Exception e, int errorCode);
> /**
> @deprecated Please use the equivalent error method which takes an Appender
> as its first parameter.
> */
> void error(String message);
>
> void error(Appender failingAppender, String message, Exception e, int errorCode);
> void error(Appender failingAppender, String message);
> }
>
> The FailoverErrorHandler would need to find all the loggers (=categories) where the
>failing appender is attached and replace it with the good appender.
>
> How does the FailoverErrorHandler know where to look for? As you know log4j supports
>multiple hierarchies and the failing appender may be attached to more than one logger.
>
> I think the solution is to let the FailoverErrorHandler to which hierarchy and
>loggers it applies. Something like:
>
> public interface ErrorHandler extends OptionHandler {
>
> /**
> Only loggers which are added to the list of loggers to check will be searched
>for
> during the appender replacement process.
> */
> public void addLoggerToCheck(Logger logger);
>
> /**
> @deprecated Please use the equivalent error method which takes an Appender
> as its first parameter.
> */
> void error(String message, Exception e, int errorCode);
> /**
> @deprecated Please use the equivalent error method which takes an Appender
> as its first parameter.
> */
> void error(String message);
>
> void error(Appender failingAppender, String message, Exception e, int errorCode);
> void error(Appender failingAppender, String message);
> }
>
> This requires that the log4j.dtd and DOMConfigurator be modified/enhanced. Do I make
>sense?
>
> Cheers, Ceki
>
> ps: I am CCing the dev list because this is of wider interest.
>
> ?Anyway, this is still a first-cut piece of code, and is just really getting to know
>the Log4J internals before I can write this code properly.
> ?
> ?Cheers,
> ?
> ?--
> ?Manik Surtani
> ?Chief Technology Officer
> ?Silk Road Limited
> ?
> ?Telephone: 07786 702 706
> ?Email: [EMAIL PROTECTED]
> ?Web: http://www.silkroad.co.uk
> ?
> ?
> ?
>
> --
> Ceki Gülcü - http://qos.ch
>
> --
> To unsubscribe, e-mail: ?mailto:[EMAIL PROTECTED]?
> For additional commands, e-mail: ?mailto:[EMAIL PROTECTED]?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
