cvs commit: logging-log4j/src/java/org/apache/log4j/db CustomSQLDBReceiver.java

sdeboy 2005/02/18 17:04:23 Modified:src/java/org/apache/log4j/db CustomSQLDBReceiver.java Log: Where clause now supported in receiver's sql statement Revision ChangesPath 1.3 +1 -0 logging-log4j/src/java/org/apache/log4j/db/CustomSQLDBReceiver.java Index

cvs commit: logging-log4j/tests/src/java/org/apache/log4j/net SMTPAppenderTest.java

ceki2005/02/18 12:46:58 Modified:tests/src/java/org/apache/log4j WriterAppenderTest.java FileAppenderTest.java ConsoleAppenderTest.java AbstractAppenderTest.java src/java/org/apache/log4j/net SMTPAppender.java Added:

Re: activateOptions pattern not desirable

On Feb 18, 2005, at 1:30 PM, Ceki Gülcü wrote: I don't think Appenders can be completely immutable. For one, you can invoke the close() method on an appender. You can also add remove filters or change the threshold of an active appender. The only appender which should be immutable is a closed ap

Use ComponentBase.getNonFloodingLogger

In 1.3alpha, some appenders in an erroneous state, may attempt to log from within their doAppend method. This just produces superfluous error messages on other appenders. To prevent this situation, appenders as well as other components should use a getNonFloodingLogger() to log error conditions

cvs commit: logging-log4j/tests build.xml

ceki2005/02/18 11:55:56 Modified:src/java/org/apache/log4j WriterAppender.java FileAppender.java testsbuild.xml Added: tests/src/java/org/apache/log4j WriterAppenderTest.java FileAppenderTest.java ConsoleAppen

Re: activateOptions pattern not desirable

I don't think Appenders can be completely immutable. For one, you can invoke the close() method on an appender. You can also add remove filters or change the threshold of an active appender. The only appender which should be immutable is a closed appender. It does not make much sense to me to h

Re: jms text msg appender

Michael, Mark (van der Voort), Do you have an interest in maintaining the JMSAppender/JMSReceiver pair? At 09:39 AM 2/16/2005, Mark van der Voort wrote: I've created a JMSAppender as Michael stated, and a matching JMSReceiver. The extension boils down to adding an optional layout to the JMSAppender

DO NOT REPLY [Bug 33595] - property substitution missed for appender

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33596] - Log file not created.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

activateOptions pattern not desirable

I obviously haven't reviewed your last commit, but you did appear to tweak with activateOptions in a few classes and mention appender lifecycle which brought the topic to mind. A very common pattern in log4j is to have a class that operates in a configuration mode early in its lifetime and then

Re: cvs commit: logging-log4j/src/java/org/apache/log4j/joran/action ParamAction.java

I forgot to mention that with this commit, I may have unintentionally broken existing appenders. However, all currently available test cases execute without problems. At 06:23 PM 2/18/2005, [EMAIL PROTECTED] wrote: ceki2005/02/18 09:23:45 Modified:tests/src/java/org/apache/log4j/ht

Re: PatternParser's map of PatternConverters

On Feb 18, 2005, at 9:44 AM, Ceki Gülcü wrote: At 04:20 PM 2/18/2005, Curt Arnold wrote: Did you intend to make globalRulesRegistry visible outside the class? Probably not but I am not 100% sure. In the near future, subclasses of PatternLayout might want to deal with formatting web server logs wi

Re: PatternParser's map of PatternConverters

At 04:20 PM 2/18/2005, Curt Arnold wrote: Did you intend to make globalRulesRegistry visible outside the class? Probably not but I am not 100% sure. In the near future, subclasses of PatternLayout might want to deal with formatting web server logs with quite different set of data. It would seem

Re: PatternParser's map of PatternConverters

On Feb 18, 2005, at 8:52 AM, Ceki Gülcü wrote: At 03:39 PM 2/18/2005, Curt Arnold wrote: Well, the idea is to have a single pattern for finding the converter to use. The converters in the global registry can be classes as they are already known at compile time. However, those in the converter re

Re: PatternParser's map of PatternConverters

At 03:39 PM 2/18/2005, Curt Arnold wrote: I was porting this cover over to log4cxx and I'm am curious why the value members of the maps in PatternParser are instances of String and not Class or Constructor? The initialization code for the static instances looks like: globalRulesRegistry.put

PatternParser's map of PatternConverters

I was porting this cover over to log4cxx and I'm am curious why the value members of the maps in PatternParser are instances of String and not Class or Constructor? The initialization code for the static instances looks like: globalRulesRegistry.put("c", LoggerPatternConverter.class.getNam

Re: cvs commit: logging-log4j/src/java/org/apache/log4j/xml XMLDecoder.java

On Feb 18, 2005, at 1:12 AM, [EMAIL PROTECTED] wrote: public Vector decodeEvents(String document) { if (document != null) { - document = document.trim(); - if (document.equals("")) { + if (document.trim().equals("")) { return null; }