cvs commit: logging-log4j/src/java/org/apache/log4j/spi LocationInfo.java

2004-01-22 Thread sdeboy
sdeboy 2004/01/22 22:39:55 Modified:src/java/org/apache/log4j/spi LocationInfo.java Log: Corrected bug that prevented locationinfo from correctly returning it's fields in some cases (socketappender->socketreceiver) Revision ChangesPath 1.17 +4 -16 logging-log4j

Re: reload behavior modification / feature request

2004-01-22 Thread Rob Butler
> ... > But, let's go one step further. Let's say that we're administrating a > cluster of servers. In some cases, I'd like to make one-off changes to one > server only, and not persist them. In other cases, I'd like to make changes > that are persisted (to a database) and made effective across the

RE: reload behavior modification / feature request

2004-01-22 Thread Paul Smith
Tom, a big +1 on everything you've said. IIRC, there are a couple of people who are very interested in this space and are interested in developing these concepts for log4j. Am I correct? It would be good if a working party could be established to push this further. Perhaps if a group could be

RE: reload behavior modification / feature request

2004-01-22 Thread Tom Drake
I've been lurking and have a few thoughts on this thread. I'm currently involved in some projects that are similar to what's being discussed. So, I'd like to chime in with my thoughts on the subject. Persistence should be an option. I can easily envision loading and saving the log4j configuration

Re: reload behavior modification / feature request

2004-01-22 Thread Paul Smith
> > > Depends on your intended purposes. JMX is a "management" api (and with JMX > remoting now a standardized protocol too). To me that means when you make a > change, the change is persistent until changed again. I would like to see via JMX the ability to modify the runtime config of log4j b

Re: reload behavior modification / feature request

2004-01-22 Thread Rob Butler
Hi, > > As to the jmx implementation, I'm not sure if overwriting the initial > log4j configuration file is the adequate approach. Or in other words, I > would prefer to not make jmx-manipulations persistent. In our opinion, a > restarted application e.g. should use the originally defined log4j > c

cvs commit: logging-log4j/docs/css site.css

2004-01-22 Thread ceki
ceki2004/01/22 12:36:35 Removed: docs/css site.css Log: site.ccs is copies from logging-site (it should not be CVS maintained here) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [E

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

2004-01-22 Thread ceki
ceki2004/01/22 11:47:43 Modified:src/java/org/apache/log4j PropertyConfigurator.java src/java/org/apache/log4j/xml DOMConfigurator.java Log: Added Rob Butler's patch. PropertyConfigurator and DOMConfigrator close the InputStream they created when configuring from

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

2004-01-22 Thread ceki
ceki2004/01/22 11:42:14 Modified:src/java/org/apache/log4j/xml DOMConfigurator.java Log: Formatting changes only (using jalopy). Revision ChangesPath 1.60 +15 -17logging-log4j/src/java/org/apache/log4j/xml/DOMConfigurator.java Index: DOMConfigurator.java

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

2004-01-22 Thread ceki
ceki2004/01/22 11:39:03 Modified:src/java/org/apache/log4j PropertyConfigurator.java Log: Formatting changes only (using jalopy). Revision ChangesPath 1.61 +6 -6 logging-log4j/src/java/org/apache/log4j/PropertyConfigurator.java Index: PropertyConfigura

cvs commit: logging-log4j/docs .cvsignore

2004-01-22 Thread ceki
ceki2004/01/22 11:32:03 Modified:docs .cvsignore Added: docs/css site.css Log: Added the docs/css/site.css to CVS control. Very minor changes. Revision ChangesPath 1.1 logging-log4j/docs/css/site.css Index: site.css ===

cvs commit: logging-log4j/docs/css - New directory

2004-01-22 Thread ceki
ceki2004/01/22 11:31:22 logging-log4j/docs/css - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug fix & reload behavior modification / feature request

2004-01-22 Thread Shapira, Yoav
Howdy, >> Does this break configureAndWatch? > >No, configureAndWatch only uses Strings which points to a file name. Thus >it never uses the doConfigure that uses a URL. The code change I made >simply closes the input stream from the URL exactly like the string version >of doConfigure does. Inf

RE: Bug fix & reload behavior modification / feature request

2004-01-22 Thread Rob Butler
> Howdy, > > >1) log4j 1.2.8 PropertyConfigurator & DOMConfigurator both have a small > bug > >in the void doConfigure(URL url, LoggerRepository repository) methods. > >They open a stream on the URL, but do not close it. This means the > file > >cannot be edited while the application is running

Message content in the event detail...

2004-01-22 Thread Alan Brown
I'd like to be able have the message in the event details section show xml in all its glory.  Currently it's not showing the tags and all newLines and leading spaces on a new line are trimmed.  I'm sending prettyPrinted xml to the log files for easy reading and I'd love to be able to view t

cvs commit: logging-log4j/src/xdocs documentation.xml

2004-01-22 Thread yoavs
yoavs 2004/01/22 07:48:47 Modified:src/xdocs documentation.xml Log: Updated class diagrams link (plify.net) per site owner's request. Revision ChangesPath 1.34 +1 -1 logging-log4j/src/xdocs/documentation.xml Index: documentation.xml

RE: Bug fix & reload behavior modification / feature request

2004-01-22 Thread Shapira, Yoav
Howdy, >1) log4j 1.2.8 PropertyConfigurator & DOMConfigurator both have a small bug >in the void doConfigure(URL url, LoggerRepository repository) methods. >They open a stream on the URL, but do not close it. This means the file >cannot be edited while the application is running because log4j h

Dynamically configuring log4j

2004-01-22 Thread Paul Glezen
Return Receipt Your document: Dynamically configuring log4j was received by: Paul Glezen/Austin/IBM at: 01/22/2004 07:32:50 PST

RE: Dynamically configuring log4j

2004-01-22 Thread Shapira, Yoav
Howdy, This is a log4j-user, not log4j-dev question, so please continue this discussion there. You would use PropertyConfigurator.configure(...) at startup, and then at any time in your application calls like Logger.getLogger("someClass").setLevel(Level.DEBUG) or Logger.getRootLogger().addAppende

DO NOT REPLY [Bug 26345] New: - Loader always uses ContextClassLoader for getting Ressources

2004-01-22 Thread bugzilla
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

Dynamically configuring log4j

2004-01-22 Thread Afsar Pasha Peeran
Hi i wanted to know is it possible to use log4j dynamically, like setting the loglevel and log mode at runtime i want the log4j to load from the property file and i want to change the properties dynamcially ( at runtime) how can i do it Your help is appreciated please let me know regards ---

Re: reload behavior modification / feature request

2004-01-22 Thread Peter Widmer
Hi Rob Rob Butler wrote: Hello all, In "The complete manual - log4j" (Printed book) pages 80 - 82 go into great detail of how log4j handles reloading/reconfiguration. Specifically it documents how reloading a config file does not have the initially expected behavior of removing all original appe