log4j.properties file location bug?

I don't know if this is a exactly bug. But is an issue and should at least be added to the FAQ I think. To get log4j to automatically load a properties file I need to explicitly add the log4j jars to the classpath. Next, I must put the properties file in the same directory as the log4j jar files.

RE: log4j.properties file location bug?

j.close(); > > //For getting the config file - for log4j > PropertyConfigurator.configure(propsLog4j); > } > catch(Exception e) { e.printStackTrace(); } > > Hope this is of some help to u. > > This is how u may not require to hard c

FileWatchdog and multiple threads

I am using log4J in a J2EE environment and would like to reload the log4j configuration if the config file changes. I know I can use FileWatchdog and doOnChange(). But I am wondering whether this is safe? Between calling resetConfiguration() and doConfigure() is there any guarantee that some other

RE: FileWatchdog and multiple threads

Could you clarify a bit. I am not quite sure what to make of your answer, "Nope" and "Log4j is thread safe" seem a bit contradictory. "Nope" could mean problems are possible and "thread safe" could mean they are not. I suppose that being thread safe (which I was aware of) does not preclude probl

DailyRollingFileAppender

It appears that the DailyRollingFileAppender does not roll on the specified period unless it is running? By this I mean if you were rolling daily at midnight, if you stop the app before midnight then start it after midnight DailyRollingFileAppender does not created a new file. I am using log4j1.1.

RE: FileWatchdog and multiple threads

Ceki, I could still use a little clarification here. From your asnwer it is not clear if it is safe to reconfig in a J2EE environment or not. Thanks Rick Hansen > > Nope. Log4j is thread safe. Ceki > > At 16:56 05.06.2001 -0500, you wrote: > >I am using log4J in a J2EE environment and would

RE: Q about RollingFileAppenders

The DailyRollingFileAppender is broken at least up to 1.1.2. I reported this a few days ago. I exepct it will be fixed in a future release. Rick Hansen > -Original Message- > From: Ulf Licht [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 21, 2001 3:28 AM > To: [EMAIL PROTECTED] > Subj

RE: Category.assert() disappointing

Here is what the javadoc says about Category.assert(): "If assertion parameter is false, then logs msg as an error statement." So I guess I would not have expected it to halt ny application. > -Original Message- > From: Zart Colwing [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 21,

RE: Category.assert() disappointing

t it in fact be FATAL and quit? I think Zart has a point... At least the logging level should be FATAL... Gino. >-Original Message----- >From: Hansen, Richard [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] >Sent: Thursday, June 21, 2001 3:53 PM >To: 'L

RE: Category.assert() disappointing

mechanism in Java (except > manually testing a > >>> condition and throwing a RuntimeException); having one > implemented in > >>> log4j > >>> doesn't seems a bad idea at first glance. > >>> > >>> But the point is org.apa

RE: Category.assert() disappointing

Junit is a testing framework. Junit's asserts are used during testing and intended to "assert" the success of a test case. Category.assert()is, I think, for testing assertions in a deployed application. I don't see how Junit helps here. Am I missing something? Besides in SDK 1.4 Java is adding a

RE: Doubt... in log4j logging .

If you look in the javadoc for PatternLayout it lists all the conversion characters. For M it says "Used to output the method name where the logging request was issued." -Original Message- From: Rajesh Tiwari [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 6:13 AM To: [EMAIL PRO

RE: Multiple JVMs writing to one log file

Have you tried this? If it doesn't work I suppsoe you could either write to a database or maybe a socket appender? Rick Hansen > -Original Message- > From: David Thielen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 26, 2001 9:29 AM > To: LOG4J Users Mailing List > Subject: RE: Multip

RE: Multiple JVMs writing to one log file

issue has been discussed > in the past > and we're (I'm) bored with it. The short answer to your > question is to > either use a SocketAppender or a JMSAppender. The mailing > list archives are > at: http://marc.theaimsgroup.com/?l=log4j-user&r=1&w=2 > >

RE: How to get the property file?

You should also be able to use ClassLoader to find a config file somewhere on the class path. Here is what I did : URL configURL = Log4JConfigurator.class.getClassLoader().getResource(configFile); PropertyConfigurator.configureAndWatch(configURL.getPath(), delay); > > Hello > > Another newbie

PatternLayout - format modifier

Can anyone explain to me why the format modifier removes chars from the end of a string and not the beginning. The behavior seems contrary to what I would expect? Is there any way to modify this behavior? Rick Hansen - To unsub

RE: pl. help on Appenders; or rather DailyRollingFileAppender

Of course the synchronization only applies to a single JVM. If you have muliple applications running in multiple JVMs all logging to the same text file, you are likely to have problems. Rick Hansen > -Original Message- > From: Seemantini Godbole [mailto:[EMAIL PROTECTED]] > Sent: Monday,

RE: properties of rollingfileappender

There is no separate, central document on properties and log4j configuration. Basically, you have to look at the JavaDoc for the appender of interest. Log4J follows the Java bean standard. The public setter methods are going to be the properties you can put in your config file. For example if I ha

RE: Is this possible for remote logging?

I don't know what a tibco message looks like or requires, but couldn't you serialize to a stream then read the stream back as as a string, or char array, or base 64 encoded or something that you can shove into the tibco message? At the other end you pull it out from the messsage, stream it out and