RE: Latest Receiver/Plugin commits to sandbox

I wonder whether we could use some Bean introspection mechanism to detect those Plugin's that support a pause operation (and perhaps other future optional operations). Paul -Original Message- From: Mark Womack To: 'Log4J Developers List' Sent: 6/21/03 9:06 AM Subject: RE: Latest Receiver/

RE: Chainsaw - Sandbox download

Scott, thanks for suggesting this alternative approach. Much appreciated. At 06:28 AM 6/20/2003 +0200, you wrote: And it really does the job - Great Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 6:13 AM To: [EMAIL PROTECTED] Subje

Re: what configuration file?

AFAIK it does not tell what file it used if you activate log4j.debug=true. On Sat, 21 Jun 2003 19:56:20 +0200, Ceki Gülcü wrote: > >I think log4j already does what you are asking for, no? > >At 07:26 PM 6/21/2003 +0200, you wrote: >>A. It seems I have to start wrestling with sourcecode again

Re: what configuration file?

I think log4j already does what you are asking for, no? At 07:26 PM 6/21/2003 +0200, you wrote: A. It seems I have to start wrestling with sourcecode again. :-) But to answer your questions: tell / log what you know. If log4j uses default init and found a properties file, then you can tell a

Re: what configuration file?

A. It seems I have to start wrestling with sourcecode again. :-) But to answer your questions: tell / log what you know. If log4j uses default init and found a properties file, then you can tell a filename, if it used an inputerstream, well, then you can't. Tom On Sat, 21 Jun 2003 11:40:00

Re: what configuration file?

Hi Tom, It is certainly not a bad idea, but how do you propose providing an "absolute path" for where the configuration file came from?  First, you cannot determine an absolute path (if you mean file system path) if the file is being loaded from an archive such as a .jar or .war file since norma

Re: [PATCH] Re: Deadlock in ReaderWriterLock after calling LogManager.shutdown ()

On Sat, 21 Jun 2003 09:41:39 +0200 Ceki Gülcü <[EMAIL PROTECTED]> wrote: > > Thank you Andy. This bug was not necessarily an easy one > to catch. my pleasure, thanks for a great logging library. > > I write crappy code and within a few days a smart person > fixes it. Hey, I > could get used t

DO NOT REPLY [Bug 20985] New: - [PATCH]support charset for SMTPAppender

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

what configuration file?

Hello developers, May I suggest a very simple addition? Either provide a function or have log4j log (log4j.debug=true) the absolute paths of the configuration files it has found. Currently I have libraries that have log4j configuration files in their JARs and of course the project itself has one.

Re: javaone concurrency presentation

Mark, Thanks for the link. Did you attend YavaWon? Doug's presentation? Had we used Doug Lea's concurrency library, the recent deadlock problem would have occurred anyhow. Some method in the Category class obtained a lock but forgot to release it. The bug was in the way concurrency API was use

Re: [PATCH] Re: Deadlock in ReaderWriterLock after calling LogManager.shutdown ()

Thank you Andy. This bug was not necessarily an easy one to catch. I write crappy code and within a few days a smart person fixes it. Hey, I could get used to this but I don't think people would put up with it for long though. :-) At 12:27 AM 6/21/2003 +0100, you wrote: Hi, The following patch

cvs commit: jakarta-log4j/src/java/org/apache/log4j Category.java

ceki2003/06/21 00:33:59 Modified:src/java/org/apache/log4j Category.java Log: Corrected quite silly but devestating bug. The patch was supplied by Andy McDonald. Revision ChangesPath 1.75 +2 -0 jakarta-log4j/src/java/org/apache/log4j/Category.java In