You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Manik Surtani <ma...@silkroad.co.uk> on 2001/11/12 15:55:54 UTC
Developing and contributing code
Hello, all.
I have been using Jakarta tools like Ant, Tomcat, and Log4J for a long
time now in our in-house Java and J2EE projects, and have been meaning
to contribute code for quite a while. I have finally got my head around
the inertia and will now, and am rearing to go. What's the best place
to start with this? I am familiar with portions of the code, have a
good understanding of the J2EE/Servlets standards and specifications.
Is there a TODO list or a wishlist for these projects, that have
features needing implementation, etc?
Cheers,
--
Manik Surtani
Chief Technology Officer
Silk Road Limited
Telephone: 07786 702 706
Email: manik.surtani@silkroad.co.uk
Web: http://www.silkroad.co.uk
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Manik Surtani <ma...@silkroad.co.uk>.
Ceki,
I take it you have already fleshed out the FallbackErrorHandler. How
about the 'self-healing' bits, though? Would you like me to do that?
Do you think it is a reasonably good idea to log to the failed appender
as well, every time, and monitor when it stops failing, and switch off
the backup appender by that time?
Cheers,
Manik
Ceki Gulcu wrote:
>Kevin,
>
>Oh, very good point. The first step is to have not option such that the temporarily failing appender is not removed (by the error handler) from the logger where it is attached. The next step is for the failing appender to have a self-healing feature such that when the connection becomes available the failing appender is able to reestablish it. SocketAppender has such capability. The composition of self-healing /failover has to be tested. More on this later. Regards, Ceki
>
>At 11:00 16.11.2001 -0800, you wrote:
>
>>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: manik.surtani@silkroad.co.uk
>>>?Web: http://www.silkroad.co.uk
>>>?
>>>?
>>>?
>>>
>>>--
>>>Ceki Gülcü - http://qos.ch
>>>
>>>--
>>>To unsubscribe, e-mail: ?mailto:log4j-dev-unsubscribe@jakarta.apache.org?
>>>For additional commands, e-mail: ?mailto:log4j-dev-help@jakarta.apache.org?
>>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Manik Surtani
Chief Technology Officer
Silk Road Limited
Telephone: 07786 702 706
Email: manik.surtani@silkroad.co.uk
Web: http://www.silkroad.co.uk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Ceki Gulcu <ce...@qos.ch>.
Kevin,
Oh, very good point. The first step is to have not option such that the temporarily failing appender is not removed (by the error handler) from the logger where it is attached. The next step is for the failing appender to have a self-healing feature such that when the connection becomes available the failing appender is able to reestablish it. SocketAppender has such capability. The composition of self-healing /failover has to be tested. More on this later. Regards, Ceki
At 11:00 16.11.2001 -0800, you wrote:
>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: manik.surtani@silkroad.co.uk
>> ?Web: http://www.silkroad.co.uk
>> ?
>> ?
>> ?
>>
>> --
>> Ceki Gülcü - http://qos.ch
>>
>> --
>> To unsubscribe, e-mail: ?mailto:log4j-dev-unsubscribe@jakarta.apache.org?
>> For additional commands, e-mail: ?mailto:log4j-dev-help@jakarta.apache.org?
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Manik Surtani <ma...@silkroad.co.uk>.
A valid point, guys.
How about using configuration settings? I.e., when configuring an
appender, we could have:
log4j.appender.MyAppender.failover.secondaryAppender=MyAlternativeAppender
log4j.appender.MyAppender.failover.removePrimary=true
If 'removePrimary' is true, the primary appender is switched off and the
secondary one takes over. Thats it.
If 'removePrimary' is set to 'false', upon failure, logs are written to
both the primary and secondary appender. If writing to the primary
appender is successful 3 times (or whatever) in consecutive, the
secondary appender is switched off again, assuming that issues with the
primary appender have been fixed, and now the primary appender takes
over on its own.
Does this make sense?
Cheers,
Manik
Kevin Steppe wrote:
>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: manik.surtani@silkroad.co.uk
>>?Web: http://www.silkroad.co.uk
>>?
>>?
>>?
>>
>>--
>>Ceki Gülcü - http://qos.ch
>>
>>--
>>To unsubscribe, e-mail: ?mailto:log4j-dev-unsubscribe@jakarta.apache.org?
>>For additional commands, e-mail: ?mailto:log4j-dev-help@jakarta.apache.org?
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Manik Surtani
Chief Technology Officer
Silk Road Limited
Telephone: 07786 702 706
Email: manik.surtani@silkroad.co.uk
Web: http://www.silkroad.co.uk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Kevin Steppe <ks...@pacbell.net>.
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: manik.surtani@silkroad.co.uk
> ?Web: http://www.silkroad.co.uk
> ?
> ?
> ?
>
> --
> Ceki Gülcü - http://qos.ch
>
> --
> To unsubscribe, e-mail: ?mailto:log4j-dev-unsubscribe@jakarta.apache.org?
> For additional commands, e-mail: ?mailto:log4j-dev-help@jakarta.apache.org?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Ceki Gülcü <ce...@qos.ch>.
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: manik.surtani@silkroad.co.uk
>Web: http://www.silkroad.co.uk
>
>
>
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Ceki Gulcu <ce...@qos.ch>.
Manik,
You might want to have a look at org.apache.log4j.AppenderSkeleton first. Cheers, Ceki
At 16:54 13.11.2001 +0000, Manik Surtani wrote:
>Hi there.
>
>I'm looking through the code now...
>
>I have looked at your ErrorHandler interface, but could not find the OnceOnlyErrorHandler. Am I missing something?
>
>Cheers,
>Manik
>
>PS: Should this be on the developers list?
>
>Ceki Gulcu wrote:
>
>>
>>Manik,
>>
>>Thanks for your offer. One interesting feature I have in mind is a FallbackErrorHandler. ErrorHandlers are attached to appenders such that they are invoked when an error occurs. Currently, all appenders come with OnceOnlyErrorHandler which reports an error once ignoring following errors (of the same appenders). A FallbackErrorHandler would replace a failing appender with a backup appender. For example, if a JDBCAppender failed for whatever reason then the FallbackErrorHandler would replace it with a say FileAppender.
>>DomConfigurator comes with support for ErrorHandlers, you "just" have to write one... Regards, Ceki
>>
>>At 14:55 12.11.2001 +0000, Manik Surtani wrote:
>>
>>>Hello, all.
>>>
>>>I have been using Jakarta tools like Ant, Tomcat, and Log4J for a long time now in our in-house Java and J2EE projects, and have been meaning to contribute code for quite a while. I have finally got my head around the inertia and will now, and am rearing to go. What's the best place to start with this? I am familiar with portions of the code, have a good understanding of the J2EE/Servlets standards and specifications. Is there a TODO list or a wishlist for these projects, that have features needing implementation, etc?
>>>
>>>Cheers,
>>>
>>>-- Manik Surtani
>>>Chief Technology Officer
>>>Silk Road Limited
>>>
>>>Telephone: 07786 702 706
>>>Email: manik.surtani@silkroad.co.uk
>>>Web: http://www.silkroad.co.uk
>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>--
>Manik Surtani
>Chief Technology Officer
>Silk Road Limited
>
>Telephone: 07786 702 706
>Email: manik.surtani@silkroad.co.uk
>Web: http://www.silkroad.co.uk
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Manik Surtani <ma...@silkroad.co.uk>.
Hi there.
I'm looking through the code now...
I have looked at your ErrorHandler interface, but could not find the
OnceOnlyErrorHandler. Am I missing something?
Cheers,
Manik
PS: Should this be on the developers list?
Ceki Gulcu wrote:
>
>Manik,
>
>Thanks for your offer. One interesting feature I have in mind is a FallbackErrorHandler. ErrorHandlers are attached to appenders such that they are invoked when an error occurs. Currently, all appenders come with OnceOnlyErrorHandler which reports an error once ignoring following errors (of the same appenders). A FallbackErrorHandler would replace a failing appender with a backup appender. For example, if a JDBCAppender failed for whatever reason then the FallbackErrorHandler would replace it with a say FileAppender.
>
>DomConfigurator comes with support for ErrorHandlers, you "just" have to write one... Regards, Ceki
>
>At 14:55 12.11.2001 +0000, Manik Surtani wrote:
>
>>Hello, all.
>>
>>I have been using Jakarta tools like Ant, Tomcat, and Log4J for a long time now in our in-house Java and J2EE projects, and have been meaning to contribute code for quite a while. I have finally got my head around the inertia and will now, and am rearing to go. What's the best place to start with this? I am familiar with portions of the code, have a good understanding of the J2EE/Servlets standards and specifications. Is there a TODO list or a wishlist for these projects, that have features needing implementation, etc?
>>
>>Cheers,
>>
>>--
>>Manik Surtani
>>Chief Technology Officer
>>Silk Road Limited
>>
>>Telephone: 07786 702 706
>>Email: manik.surtani@silkroad.co.uk
>>Web: http://www.silkroad.co.uk
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Manik Surtani
Chief Technology Officer
Silk Road Limited
Telephone: 07786 702 706
Email: manik.surtani@silkroad.co.uk
Web: http://www.silkroad.co.uk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by Ceki Gulcu <ce...@qos.ch>.
Manik,
Thanks for your offer. One interesting feature I have in mind is a FallbackErrorHandler. ErrorHandlers are attached to appenders such that they are invoked when an error occurs. Currently, all appenders come with OnceOnlyErrorHandler which reports an error once ignoring following errors (of the same appenders). A FallbackErrorHandler would replace a failing appender with a backup appender. For example, if a JDBCAppender failed for whatever reason then the FallbackErrorHandler would replace it with a say FileAppender.
DomConfigurator comes with support for ErrorHandlers, you "just" have to write one... Regards, Ceki
At 14:55 12.11.2001 +0000, Manik Surtani wrote:
>Hello, all.
>
>I have been using Jakarta tools like Ant, Tomcat, and Log4J for a long time now in our in-house Java and J2EE projects, and have been meaning to contribute code for quite a while. I have finally got my head around the inertia and will now, and am rearing to go. What's the best place to start with this? I am familiar with portions of the code, have a good understanding of the J2EE/Servlets standards and specifications. Is there a TODO list or a wishlist for these projects, that have features needing implementation, etc?
>
>Cheers,
>
>--
>Manik Surtani
>Chief Technology Officer
>Silk Road Limited
>
>Telephone: 07786 702 706
>Email: manik.surtani@silkroad.co.uk
>Web: http://www.silkroad.co.uk
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Developing and contributing code
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Nov 2001, Manik Surtani wrote:
> Date: Mon, 12 Nov 2001 14:55:54 +0000
> From: Manik Surtani <ma...@silkroad.co.uk>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: ant-user@jakarta.apache.org, tomcat-user@jakarta.apache.org,
> log4j-user@jakarta.apache.org
> Subject: Developing and contributing code
>
> Hello, all.
>
> I have been using Jakarta tools like Ant, Tomcat, and Log4J for a long
> time now in our in-house Java and J2EE projects, and have been meaning
> to contribute code for quite a while. I have finally got my head around
> the inertia and will now, and am rearing to go. What's the best place
> to start with this? I am familiar with portions of the code, have a
> good understanding of the J2EE/Servlets standards and specifications.
> Is there a TODO list or a wishlist for these projects, that have
> features needing implementation, etc?
>
The place to start is to read the guidelines that describe how Jakarta
projects work, starting at:
http://jakarta.apache.org/site/getinvolved.html
and then join the developer list for the project(s) you are interested in:
http://jakarta.apache.org/site/mail.html
It would probably also be useful to review some of the developer
conversations in the mail archives - pointers are available in the "mail"
link above.
Each project deals with TODO items in their own way, with varying degrees
of formality -- for example, in Tomcat 4 there is some ongoing discussion
about creating the "Cluster" capabilities for setting up load balanced
environment (some existing experimental code exists in the HEAD branch of
the "jakarta-tomcat-4.0" CVS repository), and for Tomcat generally the web
connectors are always in need of testing and debugging. Another very
useful way to get involved is to look at the outstanding bug reports and
submit patches - the bug tracking system is at:
http://nagoya.apache.org/bugzilla/
Welcome!
> Cheers,
>
> --
> Manik Surtani
Craig
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>