cvs commit: jakarta-log4j/src/java/org/apache/log4j/test README

ceki01/05/20 00:13:59 Modified:buildbuild.xml contribs CONTENTS docs HISTORY src/java/org/apache/log4j/test README Log: Last minute doc changes. Revision ChangesPath 1.33 +1 -0 jakarta-log4j/build/build.x

Re: [PATCH] Add handling of custom Priority subclasses to PropertyConfigurator

Still have heard nothing on this. Just pestering. Please let me know if this is acceptable or if more info/testing is necessary. Thanx! jeff Jeffrey Bonevich wrote: > > Have received no comment on this one in a week. Problems? Maybe > already covered by another patch? Please inform. Than

Re: [PATCH] Add configure with URL arg to DOMConfigurator

Submitted this a month ago. Have not heard if it is acceptable. Please respond. jeff Jeffrey Bonevich wrote: > > While working with DOMConfigurator a bit, I noticed that there is only a > single static configure method that takes a String argument, a local > file system path. I am under a ma

[PATCH] SMTPAppender.java

Here are the changes I was talking about before regarding making the SMTPAppender friendlier to extension. The patch is against rev 1.22 in CVS. Specific changes: * Private members are declared to be private. * Private members that is needed by subclasses (like the CyclicBuffer, TriggerEvent

RE: Log4J beyond 1.1 -- extensibility

Cool. I knew it wasn't personal, and the SMTPAppender wasn't the point. (I'll send the patch under a seperate header.) I just wanted to make sure that everyone writing code for the project remembers how important it is to make the code extensible via subclassing. (By not using package members/m

log4j 1.1 now available

Greetings, Log4j 1.1 is now available at http://jakarta.apache.org/log4j. This official release is identical to 1.1beta7 with the exception of minor documentation improvements. Version 1.1 is backward compatible with log4j version 1.0.x. Thus, it should be considered as a drop-in replacement f

RE: Log4J beyond 1.1, thunderdome!

Hello Jim, If you feel that your contribution is being ignored then nag. If that doesn't work, then nag some more. I would dare say that participants in the log4j project are mere mortals. That applies to other open source projects in Jakarta, XML, PHP and httpd. We make mistakes, overlook ex

RE: Log4J beyond 1.1 -- modify at runtime

At 13:06 19.05.2001 -0400, you wrote: >What is meant, exactly, by "modify log4j settings at runtime"? From a >org.apache.log4j.gui.ChangeLoggingDialog within the application being run? >Sending it a SIGHUP to reread the file? From another VM that talks over a >socket? Jim, All of the above e

cvs commit: jakarta-log4j/contribs/VolkerMentzner HTTPRequestHandler.java Log4jRequestHandler.java PluggableHTTPServer.java RootRequestHandler.java UserDialogRequestHandler.java mail-03-05-2001

ceki01/05/19 13:42:50 Added: contribs/VolkerMentzner HTTPRequestHandler.java Log4jRequestHandler.java PluggableHTTPServer.java RootRequestHandler.java UserDialogRequestHandler.java mail-03-05-2001 Log: Add

cvs commit: jakarta-log4j/contribs/VolkerMentzner - New directory

ceki01/05/19 13:37:19 jakarta-log4j/contribs/VolkerMentzner - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

RE: Log4J beyond 1.1 -- modify at runtime

What is meant, exactly, by "modify log4j settings at runtime"? From a org.apache.log4j.gui.ChangeLoggingDialog within the application being run? Sending it a SIGHUP to reread the file? From another VM that talks over a socket? -Jim Moore -Original Message- From: Ceki Gulcu [mailto:[EM

RE: Log4J beyond 1.1, thunderdome!

My #1 request is that the code be written in a way that can be extended. A great deal of the current code is written with critical sections using package members/methods without any accessor methods to get to them. That means that if you want to extend a class, you simply can't do so -- you must