RE: More Filter Thoughts

Mark, There is not an ounce of doubt that you understand log4j filters. We have come a long way once you started looking into filters. Thank you! The only beef I have is with the name ChainableFilterBase. I have not seen your code so there is a good chance than I am overlooking some aspects.

Re: Binary compatibility between versions of log4j

On Thu, Jun 06, 2002 at 10:25:11AM -0400, Scott Miller wrote: > Yes, the options seem to be many > > 1) Don't upgrade, in which case bug fixes can either be performed by > A) Log4J developers. > B) You. Bugs? For the last 2 years, we've run log4j 0.8.3 in our core app. Never had any problem

RE: More Filter Thoughts

I just want to make clear that I DO UNDERSTAND that filters, by their nature and implementation in log4j, are chainable, etc. I think this aspect is not fully understood by many of the log4j users, so I am trying to create a base class that exposes this functionality in a way that helps in the un

RE: More Filter Thoughts

> 2) we find a different name for ChainableFilterBase, for example > BasicFilter or FilterCore. > > The second option seems somewhat wiser because the basic notion of > chaining filters is not being challenged. OK. I was just trying to capture the aspect that filters subclassing from this base

Re: Binary compatibility between versions of log4j

On Thursday 06 June 2002 22:18, Anders Kristensen wrote: > Well, you always have the option of not upgrading to newer versions of > log4j. It sounds like that's the strategy you've chosen for JDBC > drivers. Then what you need is a assurance that the old version you're > using will continue to be

DO NOT REPLY [Bug 9514] - Chainsaw cannot load files if messages contain CDATA

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 9462] - make default initialization available as a public method

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://nagoya.apache.org/bugzilla/show_bu

Re: TelnetAppender change recommendation

This is nice and easy. How about supporting the size of the backlog as an option? At 12:07 06.06.2002 -0500, you wrote: >The TelnetAppender is extremely convenient, providing access to the >running log no matter where you are, since nearly all operating systems >now have a basic telnet clien

Re: PatternLayout extensions & Log4j JDBCAppender

There is an example in examples/ directory. Adding a new conversion character is indeed a natural continuation of your current approach which I must say is ill advised. Escaping quotes is one issue that PreparedStatements solve trivially. PreparedStatements are a mandatory part of the JDBC spec w

PatternLayout extensions & Log4j JDBCAppender

After digging into the throwable info in a JDBCAppender a littler here is my current idea: Use an extension to the PatternLayout, which can convert the throwable into a single string (with colons, or \n, or whatever in between). This new conversion character code then be placed in the normal

Re: Error Handler & Log4j JDBCAppender

> Does OnlyOnceErrorHandler ring a bell? :-) *slow nod of understanding* Thanks. Kevin -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: Error Handler & Log4j JDBCAppender

At 10:47 06.06.2002 -0700, you wrote: >I ran some tests to generate errors in flushBuffer() [lines 226-280]. The >first instance of errorHandler.error generated some console output. The >second instance (line 267) did not generate anything. I did not specify >any particular errorHandler. Whe

Error Handler & Log4j JDBCAppender

I ran some tests to generate errors in flushBuffer() [lines 226-280]. The first instance of errorHandler.error generated some console output. The second instance (line 267) did not generate anything. I did not specify any particular errorHandler. When I placed a System.out.println inside t

TelnetAppender change recommendation

The TelnetAppender is extremely convenient, providing access to the running log no matter where you are, since nearly all operating systems now have a basic telnet client built into them. Unfortunately I was unable to live with the most glaring shortcoming, that the appender forces you to wait

RE: Binary compatibility between versions of log4j

> To get to the point I would really like the developers of > log4j to say "We > are willing to maintain x subset of our API forever with 100% backward > compatibility". I understand completely why you would be > reluctant to make > such a commitment but I would like to try and tempt you: Anothe

RE: Binary compatibility between versions of log4j

In case I was not clear, the Category class will not be removed before mid 2003. This does NOT mean that it will be removed on the 1st of June 2003. It may be removed in 2005 or... never. At 07:02 06.06.2002 -0700, Doug wrote: >well said. the Logger -> Category change is quite >significant and

RE: Binary compatibility between versions of log4j

Yes, the options seem to be many 1) Don't upgrade, in which case bug fixes can either be performed by A) Log4J developers. B) You. 2) Create an interface wrapper around Log4J (akin to apache commons logging) that you control, and can swap out Log4J for another implementation if it ceases to

Re: Binary compatibility between versions of log4j

Well, you always have the option of not upgrading to newer versions of log4j. It sounds like that's the strategy you've chosen for JDBC drivers. Then what you need is a assurance that the old version you're using will continue to be maintained and have bugs fixed etc. That's a very different t

RE: Binary compatibility between versions of log4j

well said. the Logger -> Category change is quite significant and raised some concerns of mine as well. --- John Armstrong <[EMAIL PROTECTED]> wrote: > I fully agree with the points you make - and thank > you for clarifying the > expected lifecycle of log4j. > > Unfortunately your answer doesn'

RE: Binary compatibility between versions of log4j

I fully agree with the points you make - and thank you for clarifying the expected lifecycle of log4j. Unfortunately your answer doesn't alleviate all my concerns. In a nutshell my problem is that using any third party software exposes code I release to risk and I am trying to evaluate the risk i

DO NOT REPLY [Bug 9606] - NTEventLogAppender.dll missing in .zip file

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://nagoya.apache.org/bugzilla/show_bu

Re: Binary compatibility between versions of log4j

John, This is a deep and tough question. The problem of binary compatibility is intrinsic to the nature of software. On one side, unlike other engineering endeavors, software can be easily modified and enhanced. On the other side, this make it very easy to break compatibility with previous versio

Binary compatibility between versions of log4j

What guarantees are there (if any) for binary compatibility between different versions of log4j? We have recently had to upgrade from version 1.0.4 of log4j to version 1.1.3. I was surprised to notice that there was not complete binary compatibility between these releases though fortunately it wa