Re: config file reloading
I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake At 03:48 PM 8/27/2003 -0700, you wrote: Hello, I was planning on using the FileWatchdog class (via DOMConfigurator) to cause my log4j.xml file to be reloaded whenever it is changed, avoiding having to bounce the webapp during debug. My problem is that I rely on the default initialization mechanism in log4j to find the file, so I don't have the filename. I'm currently looking at modifying the dtd to add a watch option so the DOMConfigurator can setup the watchdog during init. Is there a better way to do this?? I'm building a package for use by our web-apps and standalone-apps, so I need something that works well in both environments. Any thoughts?? --- regards --- Larry -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Behaviour in Log4j when Logfile is deleted.
Hi all, I am using Lo4j 1.2.8, During the cource of my application running i deleted the log file. Now there is no exception/error thrown. The application keeps on running ,possibly ignoring the logging part. Whys is this behaviour happening, Thanks and regards Rohith This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this e-mail. We cannot accept liability for any loss or damage caused by software viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this e-mail. We cannot accept liability for any loss or damage caused by software viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
Oh, and I forgot to mention setting the -Dlog4j.configuration system property which you can poll to find where log4j.xml exists. Jake At 06:09 PM 8/27/2003 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake At 03:48 PM 8/27/2003 -0700, you wrote: Hello, I was planning on using the FileWatchdog class (via DOMConfigurator) to cause my log4j.xml file to be reloaded whenever it is changed, avoiding having to bounce the webapp during debug. My problem is that I rely on the default initialization mechanism in log4j to find the file, so I don't have the filename. I'm currently looking at modifying the dtd to add a watch option so the DOMConfigurator can setup the watchdog during init. Is there a better way to do this?? I'm building a package for use by our web-apps and standalone-apps, so I need something that works well in both environments. Any thoughts?? --- regards --- Larry -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log file location
The properties file is not being read at all
I placed it in WEB-INF/classes.
Still it's not being read.
I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml in
default/conf folder.
Probably even my application is taking log4j.xml from that location by default. I need
to check that. Anyone who has implemented log4j for their applications on JBoss, pl.
suggest.
Sriram
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 6:52 PM
To: Log4J Users List
Subject: Re: Log file location
Is the properties file being read at all?
At 06:25 PM 8/27/2003 +0530, sriram wrote:
Hi,
I am unable to set log file location. I searched the forum for old
messages and found some. I tried the way it was mentioned in those
messages, but still my problem is not solved.
My log4j.properties file is as follows:
log4j.rootCategory=WARN, dest1, R
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
log4j.appender.dest1.layout.ConversionPattern=%-5p: %m%n
appender writes to a file
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%-5p: %m%n
log4j.appender.R.File=d:/jboss/errors.log
I packaged by application as .ear and deployed it on JBoss running on
Win
2000.
When I run the application, I can see the log messages on JBoss
console,
but these messages are not getting stored in the file I've specified
(d:/jboss/errors.log).
What could be the problem? In fact, initially I tried
${jboss.home}/errors.log, but it didn't work. So I thought of hard coding
the file location and tried it out. Still the same problem.
Can someone please suggest a solution?
Thanks
Sriram
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log file location
Hi Sriram,
Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default
initialization not to work. Remember that the webapp class loader can see
parent class loaders, but the parents cannot see the webapp class loader,
hence your log4j.properties will definitely not be found. If you are
trying to use log4j.jar in a parent class loader and want your own
configuration file to be used in your own logging space, then you will need
to use a repository selector. See the log4j-sandbox for working
examples. I wrote something up about this stuff here...
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
Jake
At 09:35 AM 8/28/2003 +0530, you wrote:
The properties file is not being read at all
I placed it in WEB-INF/classes.
Still it's not being read.
I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml in
default/conf folder.
Probably even my application is taking log4j.xml from that location by
default. I need to check that. Anyone who has implemented log4j for their
applications on JBoss, pl. suggest.
Sriram
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 6:52 PM
To: Log4J Users List
Subject: Re: Log file location
Is the properties file being read at all?
At 06:25 PM 8/27/2003 +0530, sriram wrote:
Hi,
I am unable to set log file location. I searched the forum for old
messages and found some. I tried the way it was mentioned in those
messages, but still my problem is not solved.
My log4j.properties file is as follows:
log4j.rootCategory=WARN, dest1, R
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
log4j.appender.dest1.layout.ConversionPattern=%-5p: %m%n
appender writes to a file
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%-5p: %m%n
log4j.appender.R.File=d:/jboss/errors.log
I packaged by application as .ear and deployed it on JBoss running on
Win
2000.
When I run the application, I can see the log messages on JBoss
console,
but these messages are not getting stored in the file I've specified
(d:/jboss/errors.log).
What could be the problem? In fact, initially I tried
${jboss.home}/errors.log, but it didn't work. So I thought of hard coding
the file location and tried it out. Still the same problem.
Can someone please suggest a solution?
Thanks
Sriram
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log file location
Hi Jake,
Thanks for the information. I have gone through the stuff you've written.
Here's what I'm doing:
1. I placed log4j-1.2.8.jar in WEB-INF/lib
2. I placed log4j.properties in WEB-INF/classes
3. I deployed the application on JBoss 3.2.1
By default, JBoss has log4j.jar in jboss/lib which is in my classpath.
So, even my application class loader takes the classes from log4j.jar located in
jboss/lib?
If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss.
How to solve this issue? Please inform.
Sriram
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 11:00 AM
To: Log4J Users List
Subject: RE: Log file location
Hi Sriram,
Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default
initialization not to work. Remember that the webapp class loader can see
parent class loaders, but the parents cannot see the webapp class loader,
hence your log4j.properties will definitely not be found. If you are
trying to use log4j.jar in a parent class loader and want your own
configuration file to be used in your own logging space, then you will need
to use a repository selector. See the log4j-sandbox for working
examples. I wrote something up about this stuff here...
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
Jake
At 09:35 AM 8/28/2003 +0530, you wrote:
The properties file is not being read at all
I placed it in WEB-INF/classes.
Still it's not being read.
I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml
in
default/conf folder.
Probably even my application is taking log4j.xml from that location by
default. I need to check that. Anyone who has implemented log4j for their
applications on JBoss, pl. suggest.
Sriram
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 6:52 PM
To: Log4J Users List
Subject: Re: Log file location
Is the properties file being read at all?
At 06:25 PM 8/27/2003 +0530, sriram wrote:
Hi,
I am unable to set log file location. I searched the forum for old
messages and found some. I tried the way it was mentioned in those
messages, but still my problem is not solved.
My log4j.properties file is as follows:
log4j.rootCategory=WARN, dest1, R
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
log4j.appender.dest1.layout.ConversionPattern=%-5p: %m%n
appender writes to a file
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%-5p: %m%n
log4j.appender.R.File=d:/jboss/errors.log
I packaged by application as .ear and deployed it on JBoss running
on Win 2000.
When I run the application, I can see the log messages on JBoss
console, but these messages are not getting stored in the file I've
specified (d:/jboss/errors.log).
What could be the problem? In fact, initially I tried
${jboss.home}/errors.log, but it didn't work. So I thought of hard
coding the file location and tried it out. Still the same problem.
Can someone please suggest a solution?
Thanks
Sriram
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log file location
We should have a look at the jboss mailing lists. JBoss' class loader is
called UnifiedClassLoader. The last time I look at UnifiedClassLoaders
about a year ago, it seemed very smart. I'd have to look at the details again.
At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote:
Well, if you your app is seeing jboss/lib/log4j.jar in preference to
WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec
states that (contrary to the normal Java2 classloading scheme) classes and
libraries in WEB-INF/classes and WEB-INF/lib are checked first for
classloading and if the classes are not found there, only then does it
look to a higher classloader to attempt to load the classes.
I know JBoss has some concept of a single classloader across the whole
server (I think that is what I read), but if it doesn't allow for a
separate WebappClassLoader, then I think it is a spec compliance
violation. What does the JBoss group have to say about this? Putting
log4j.jar in WEB-INF/lib *should* provide a completely separate logging
environment from the one JBoss uses.
Jake
At 12:09 PM 8/28/2003 +0530, you wrote:
Hi Jake,
Thanks for the information. I have gone through the stuff you've written.
Here's what I'm doing:
1. I placed log4j-1.2.8.jar in WEB-INF/lib
2. I placed log4j.properties in WEB-INF/classes
3. I deployed the application on JBoss 3.2.1
By default, JBoss has log4j.jar in jboss/lib which is in my classpath.
So, even my application class loader takes the classes from log4j.jar
located in jboss/lib?
If I remove log4j.jar in jboss/lib, then I think I will not get server
log of JBoss.
How to solve this issue? Please inform.
Sriram
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 11:00 AM
To: Log4J Users List
Subject: RE: Log file location
Hi Sriram,
Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default
initialization not to work. Remember that the webapp class loader can see
parent class loaders, but the parents cannot see the webapp class loader,
hence your log4j.properties will definitely not be found. If you are
trying to use log4j.jar in a parent class loader and want your own
configuration file to be used in your own logging space, then you will need
to use a repository selector. See the log4j-sandbox for working
examples. I wrote something up about this stuff here...
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
Jake
At 09:35 AM 8/28/2003 +0530, you wrote:
The properties file is not being read at all
I placed it in WEB-INF/classes.
Still it's not being read.
I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml
in
default/conf folder.
Probably even my application is taking log4j.xml from that location by
default. I need to check that. Anyone who has implemented log4j for their
applications on JBoss, pl. suggest.
Sriram
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 6:52 PM
To: Log4J Users List
Subject: Re: Log file location
Is the properties file being read at all?
At 06:25 PM 8/27/2003 +0530, sriram wrote:
Hi,
I am unable to set log file location. I searched the forum for old
messages and found some. I tried the way it was mentioned in those
messages, but still my problem is not solved.
My log4j.properties file is as follows:
log4j.rootCategory=WARN, dest1, R
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
log4j.appender.dest1.layout.ConversionPattern=%-5p: %m%n
appender writes to a file
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%-5p: %m%n
log4j.appender.R.File=d:/jboss/errors.log
I packaged by application as .ear and deployed it on JBoss running
on Win 2000.
When I run the application, I can see the log messages on JBoss
console, but these messages are not getting stored in the file I've
specified (d:/jboss/errors.log).
What could be the problem? In fact, initially I tried
${jboss.home}/errors.log, but it didn't work. So I thought of hard
coding the file location and tried it out. Still the same problem.
Can someone please suggest a solution?
Thanks
Sriram
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Behaviour in Log4j when Logfile is deleted.
Hi all, I am using Lo4j 1.2.8, During the cource of my application running i deleted the log file. Now there is no exception/error thrown. The application keeps on running ,possibly ignoring the logging part. Whys is this behaviour happening,should the log4j throw exception as its no longer finding the Log File. Thanks and regards Rohith This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this e-mail. We cannot accept liability for any loss or damage caused by software viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this e-mail. We cannot accept liability for any loss or damage caused by software viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this e-mail. We cannot accept liability for any loss or damage caused by software viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SizeBasedTriggeringPolicy $ TimeBasedRollingPolicy
Hi all!
I'm getting started with log4j programming and i have my first doubt.
I want a logger size based triggering policy and time based rolling policy
so i'm using SizeBasedTriggeringPolicy and TimeBasedRollingPolicy in the
following way:
Logger root = Logger.getRootLogger();
root.addAppender(new ConsoleAppender(new PatternLayout()));
PatternLayout layout = new PatternLayout(%c{1} - %m%n);
RollingFileAppender rfa = new RollingFileAppender();
rfa.setLayout(layout);
TimeBasedRollingPolicy tbrp = new TimeBasedRollingPolicy();
SizeBasedTriggeringPolicy sbtp = new SizeBasedTriggeringPolicy();
tbrp.setActiveFileName(my_log);
tbrp.setFileNamePattern(my_log_%d{-MM-dd_HH_mm_ss});
sbtp.setMaxFileSize(100);
rfa.setRollingPolicy(tbrp);
rfa.setTriggeringPolicy(sbtp);
rfa.activateOptions();
root.addAppender(rfa);
for (int i = 0; i 200; i++) {
try{
Thread.sleep(1000);
}catch(Exception e){}
if (i 10) {
logger.debug(Hello + i);
} else if (i 100) {
logger.debug(Hello + i);
}
}
An i get the following error when max size is reached:
The date pattern is [-MM-dd_HH_mm_ss] from file name pattern
[my_log_%d{yy
-MM-dd_HH_mm_ss}].
Rollover every second.
getActiveLogFileName called
Active log file name: my_log
Hello 11
Hello 12
Hello 13
Hello 14
About to rollover
rollover called
compressionMode: 0
activeFileName: my_log
currentFileName: null
Exception in thread main java.lang.NullPointerException
at java.io.File.init(File.java:180)
at org.apache.log4j.rolling.helpers.Util.rename(Util.java:68)
at org.apache.log4j.rolling.TimeBasedRollingPolicy.rollover(TimeBasedR
lingPolicy.java:175)
at org.apache.log4j.rolling.RollingFileAppender.rollover(RollingFileAp
nder.java:124)
at org.apache.log4j.rolling.RollingFileAppender.subAppend(RollingFileA
ender.java:153)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:181)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:27
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppende
(AppenderAttachableImpl.java:100)
at org.apache.log4j.Category.callAppenders(Category.java:253)
at org.apache.log4j.Category.forcedLog(Category.java:464)
at org.apache.log4j.Category.debug(Category.java:317)
at com.foo.Pruebas_log4j.main(Pruebas_log4j.java:101)
I could see TimeBasedRollingPolicy 'changes' the logfile name in method
isTriggeringEvent but only sizebased triggering event method is invoked as
is the only triggering policy configured for RollingFileAppender.
Am i wrong or may i overwrite timebasedrollingpolicy to force the change of
the logfile name when rollover() is invoked?
Thanks for all
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SizeBasedTriggeringPolicy $ TimeBasedRollingPolicy
Hello Delphina,
TimeBasedRollingPolicy is somewhat special. It is declared as:
public class TimeBasedRollingPolicy extends RollingPolicySkeleton
implements TriggeringPolicy {
}
Thus, it combines both a rolling policy and a triggering policy. Look at
the tests cases under /tests/src/o/a/log4j/rolling to see how it is used.
I think you should first study TimeBasedRollingPolicy and then either
create a new class based on TimeBasedRollingPolicy or extend
TimeBasedRollingPolicy overriding the isTriggeringEvent method.
Let me know if this helps,
At 11:09 AM 8/28/2003 +0200, Delfina Concepcion wrote:
Hi all!
I'm getting started with log4j programming and i have my first doubt.
I want a logger size based triggering policy and time based rolling policy
so i'm using SizeBasedTriggeringPolicy and TimeBasedRollingPolicy in the
following way:
Logger root = Logger.getRootLogger();
root.addAppender(new ConsoleAppender(new PatternLayout()));
PatternLayout layout = new PatternLayout(%c{1} - %m%n);
RollingFileAppender rfa = new RollingFileAppender();
rfa.setLayout(layout);
TimeBasedRollingPolicy tbrp = new TimeBasedRollingPolicy();
SizeBasedTriggeringPolicy sbtp = new SizeBasedTriggeringPolicy();
tbrp.setActiveFileName(my_log);
tbrp.setFileNamePattern(my_log_%d{-MM-dd_HH_mm_ss});
sbtp.setMaxFileSize(100);
rfa.setRollingPolicy(tbrp);
rfa.setTriggeringPolicy(sbtp);
rfa.activateOptions();
root.addAppender(rfa);
for (int i = 0; i 200; i++) {
try{
Thread.sleep(1000);
}catch(Exception e){}
if (i 10) {
logger.debug(Hello + i);
} else if (i 100) {
logger.debug(Hello + i);
}
}
An i get the following error when max size is reached:
The date pattern is [-MM-dd_HH_mm_ss] from file name pattern [my_log_%d{yy
-MM-dd_HH_mm_ss}].
Rollover every second.
getActiveLogFileName called
Active log file name: my_log
Hello 11
Hello 12
Hello 13
Hello 14
About to rollover
rollover called
compressionMode: 0
activeFileName: my_log
currentFileName: null
Exception in thread main java.lang.NullPointerException
at java.io.File.init(File.java:180)
at org.apache.log4j.rolling.helpers.Util.rename(Util.java:68)
at org.apache.log4j.rolling.TimeBasedRollingPolicy.rollover(TimeBasedR
lingPolicy.java:175)
at org.apache.log4j.rolling.RollingFileAppender.rollover(RollingFileAp
nder.java:124)
at org.apache.log4j.rolling.RollingFileAppender.subAppend(RollingFileA
ender.java:153)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:181)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:27
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppende
(AppenderAttachableImpl.java:100)
at org.apache.log4j.Category.callAppenders(Category.java:253)
at org.apache.log4j.Category.forcedLog(Category.java:464)
at org.apache.log4j.Category.debug(Category.java:317)
at com.foo.Pruebas_log4j.main(Pruebas_log4j.java:101)
I could see TimeBasedRollingPolicy 'changes' the logfile name in method
isTriggeringEvent but only sizebased triggering event method is invoked as
is the only triggering policy configured for RollingFileAppender.
Am i wrong or may i overwrite timebasedrollingpolicy to force the change
of the logfile name when rollover() is invoked?
Thanks for all
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[HOWTO] DOMConfigurator in JBoss
Hi, I'm trying to use the DOMConfigurator in a J2EE application that runs in Jboss 3.2.1. Since I want to configure the logging per application and have more than one application in a Jboss server running, I want a log4j-configuration.xml per .EAR file that defines the logging of that application. My intention is to find this XML file independent of the location, as long as it is deployed with the EAR. But when I use DOMConfigurator.configure(ClassLoader.getSystemResource(log4j-configuration .xml)) I get an NPE, when I provide the URL myself hardcoded (eg localhost:8280/testapp/log4j-configuration.xml) all works fine. But I don't want to hardcode the URL since it depends too much on too many things, like ports and IPs. And I also don't want to change the log4j.xml that is in the conf directory of Jboss, as it would require too much handwork everytime I add another application to the container. Anybody a solution to this? Thanks in advance, Iwan Eising IT-Titans +31 611 198 184 / [EMAIL PROTECTED] Note: The information contained in this email is privileged and confidential information intended for the use of the addressee. If the reader of this email is not the intended recipient, or the employee or agent thereof, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you received this email in error, please immediately notify the sender listed above and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log file location
Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file location Hi Sriram, Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default initialization not to work. Remember that the webapp class loader can see parent class loaders, but the parents cannot see the webapp class loader, hence your log4j.properties will definitely not be found. If you are trying to use log4j.jar in a parent class loader and want your own configuration file to be used in your own logging space, then you will need to use a repository selector. See the log4j-sandbox for working examples. I wrote something up about this stuff here... http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppCont ainerLogging Jake At 09:35 AM 8/28/2003 +0530, you wrote: The properties file is not being read at all I placed it in WEB-INF/classes. Still it's not being read. I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml in default/conf folder. Probably even my application is taking log4j.xml from that location by default. I need to check that. Anyone who has implemented log4j for their applications on JBoss, pl. suggest. Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 6:52 PM To: Log4J Users List Subject: Re: Log file location Is the properties file being read at all? At 06:25 PM 8/27/2003 +0530, sriram wrote: Hi, I am unable to set log file location. I searched the forum for old messages and found some. I tried the way it was mentioned in those messages, but still my problem is not solved. My log4j.properties file is as follows: log4j.rootCategory=WARN, dest1, R log4j.appender.dest1=org.apache.log4j.ConsoleAppender log4j.appender.dest1.layout=org.apache.log4j.PatternLayout log4j.appender.dest1.layout.ConversionPattern=%-5p: %m%n appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout
RE: Log file location
Sriram, We have not yet added the code to automatically read configuration files when a repository is first accessed. However, nothing prevents you from configuring a repository in your applications. As for using and installing JNDIRS, JBoss has very cool ways for installing plugins. You might want to write a plugin that installs JNDIRS (JNDI Repository Selector) through org.apache.log4j.LogManager's setRepositorySelector() method. All this might be somewhat complicated at the beginning. Why don't you just configure the log4j settings of JBoss? Wouldn't that be the easiest option? At 06:27 PM 8/28/2003 +0530, sriram wrote: Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file location Hi Sriram, Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default initialization not to work. Remember that the webapp class loader can see parent class loaders, but the parents cannot see the webapp class loader, hence your log4j.properties will definitely not be found. If you are trying to use log4j.jar in a parent class loader and want your own configuration file to be used in your own logging space, then you will need to use a repository selector. See the log4j-sandbox for working examples. I wrote something up about this stuff here... http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppCont ainerLogging Jake At 09:35 AM 8/28/2003 +0530, you wrote: The properties file is not being read at all I placed it in WEB-INF/classes. Still it's not being read. I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml in default/conf folder. Probably even my application is taking log4j.xml from that location by default. I need to check that. Anyone who has implemented log4j for their applications on JBoss, pl. suggest. Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 6:52 PM To: Log4J Users List Subject: Re: Log file location Is the properties file being read at all? At 06:25 PM 8/27/2003 +0530, sriram wrote: Hi,
RE: Log file location
Yes, I have done that and it's working. I have used log4j.xml of jboss (located in server/default/conf). I have added by own category in that: category name=com.mypackage priority value=ERROR/ /category So, all ERROR level messages generated in mypackage are written to server.log. But this server.log contains all the info that is being logged by JBoss by default also (I mean all the JBoss log information also is included in this server.log apart my application log). I thought it would be a better idea to separate the application log with that of JBoss server log and so I am trying that out. But I wonder is there any way in which I can configure the following using JBoss's log4j.xml: - All server logs should be written to server.log - All Myapplication logs should be written to myapplication.log Basically log output should be directed to two files. Is this possible? Please inform. -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 8:09 PM To: Log4J Users List Subject: RE: Log file location Sriram, We have not yet added the code to automatically read configuration files when a repository is first accessed. However, nothing prevents you from configuring a repository in your applications. As for using and installing JNDIRS, JBoss has very cool ways for installing plugins. You might want to write a plugin that installs JNDIRS (JNDI Repository Selector) through org.apache.log4j.LogManager's setRepositorySelector() method. All this might be somewhat complicated at the beginning. Why don't you just configure the log4j settings of JBoss? Wouldn't that be the easiest option? At 06:27 PM 8/28/2003 +0530, sriram wrote: Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file location Hi Sriram, Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default initialization not to work. Remember that the webapp class loader can see parent class loaders, but the parents cannot see the
RE: Log file location
Yes, that is possible by using attaching an appender to com.mypackage and setting appender additivity to false. Please refer to log4j documentation at http://jakarta.apache.org/log4j/docs/documentation.html At 08:09 PM 8/28/2003 +0530, you wrote: Yes, I have done that and it's working. I have used log4j.xml of jboss (located in server/default/conf). I have added by own category in that: category name=com.mypackage priority value=ERROR/ /category So, all ERROR level messages generated in mypackage are written to server.log. But this server.log contains all the info that is being logged by JBoss by default also (I mean all the JBoss log information also is included in this server.log apart my application log). I thought it would be a better idea to separate the application log with that of JBoss server log and so I am trying that out. But I wonder is there any way in which I can configure the following using JBoss's log4j.xml: - All server logs should be written to server.log - All Myapplication logs should be written to myapplication.log Basically log output should be directed to two files. Is this possible? Please inform. -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 8:09 PM To: Log4J Users List Subject: RE: Log file location Sriram, We have not yet added the code to automatically read configuration files when a repository is first accessed. However, nothing prevents you from configuring a repository in your applications. As for using and installing JNDIRS, JBoss has very cool ways for installing plugins. You might want to write a plugin that installs JNDIRS (JNDI Repository Selector) through org.apache.log4j.LogManager's setRepositorySelector() method. All this might be somewhat complicated at the beginning. Why don't you just configure the log4j settings of JBoss? Wouldn't that be the easiest option? At 06:27 PM 8/28/2003 +0530, sriram wrote: Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file
RE: Log file location
At 06:27 PM 8/28/2003 +0530, you wrote: Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); You don't need to do that if you are using a logger repository. Just use LogManager.setLoggerRepostiory() and define your logger like normal... private static final Logger logger = Logger.getLogger(MyApp.class.getName()); See info about using repository selectors plus 2 selectors which have already been written (mirrors, but somewhat modifies code in Ceki's article) http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging Ceki mentioned JBoss plugins. You could set up a plugin to install the repository selector at JBoss startup and you would be guaranteed to have a separate logging environment. Otherwise, run the IniContextListener servlet context listener in the logj4-sandbox to set things up. Jake logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file location Hi Sriram, Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default initialization not to work. Remember that the webapp class loader can see parent class loaders, but the parents cannot see the webapp class loader, hence your log4j.properties will definitely not be found. If you are trying to use log4j.jar in a parent class loader and want your own configuration file to be used in your own logging space, then you will need to use a repository selector. See the log4j-sandbox for working examples. I wrote something up about this stuff here... http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppCont ainerLogging Jake At 09:35 AM 8/28/2003 +0530, you wrote: The properties file is not being read at all I placed it in WEB-INF/classes. Still it's not being read. I am JBoss and JBoss contains log4j.jar by default and it has log4j.xml in default/conf folder. Probably even my application is taking log4j.xml from that location by default. I need to check that. Anyone who has implemented log4j for their applications on JBoss, pl. suggest. Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 6:52
RE: Log file location
At 08:09 PM 8/28/2003 +0530, you wrote: I thought it would be a better idea to separate the application log with that of JBoss server log and so I am trying that out. But I wonder is there any way in which I can configure the following using JBoss's log4j.xml: - All server logs should be written to server.log - All Myapplication logs should be written to myapplication.log Basically log output should be directed to two files. Is this possible? Please inform. Of course. Configure a separate appender for your own application logging. Jake -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 8:09 PM To: Log4J Users List Subject: RE: Log file location Sriram, We have not yet added the code to automatically read configuration files when a repository is first accessed. However, nothing prevents you from configuring a repository in your applications. As for using and installing JNDIRS, JBoss has very cool ways for installing plugins. You might want to write a plugin that installs JNDIRS (JNDI Repository Selector) through org.apache.log4j.LogManager's setRepositorySelector() method. All this might be somewhat complicated at the beginning. Why don't you just configure the log4j settings of JBoss? Wouldn't that be the easiest option? At 06:27 PM 8/28/2003 +0530, sriram wrote: Ceki, I'm trying the way you have mentioned at http://www.qos.ch/logging/sc.html (using LoggerRepository). In my java class, I have the following code: (I'm using JNDIRS you've mentioned in the above URL) private static final JNDIRS jndirs = new JNDIRS(); private static final LoggerRepository loggerRepository = jndirs.getLoggerRepository(); private static final Logger logger = loggerRepository.getLogger(MyApp.class.getName()); logger.warn(Just testing a log message with priority set to WARN); My log4j.properties file is as follows: appender writes to a file log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%-5p: %m%n log4j.appender.R.File=errors.log Still I feel that my log4j.properties file not being read, because I can't see errors.log created anywhere. And there are no errors throws. Any idea what could be the problem? Can you pl. suggest a solution? Sriram -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:58 PM To: Log4J Users List Subject: RE: Log file location We should have a look at the jboss mailing lists. JBoss' class loader is called UnifiedClassLoader. The last time I look at UnifiedClassLoaders about a year ago, it seemed very smart. I'd have to look at the details again. At 02:05 AM 8/28/2003 -0500, Jacob Kjome wrote: Well, if you your app is seeing jboss/lib/log4j.jar in preference to WEB-INF/lib/log4j.jar, then there is a bug in JBoss. The Servlet spec states that (contrary to the normal Java2 classloading scheme) classes and libraries in WEB-INF/classes and WEB-INF/lib are checked first for classloading and if the classes are not found there, only then does it look to a higher classloader to attempt to load the classes. I know JBoss has some concept of a single classloader across the whole server (I think that is what I read), but if it doesn't allow for a separate WebappClassLoader, then I think it is a spec compliance violation. What does the JBoss group have to say about this? Putting log4j.jar in WEB-INF/lib *should* provide a completely separate logging environment from the one JBoss uses. Jake At 12:09 PM 8/28/2003 +0530, you wrote: Hi Jake, Thanks for the information. I have gone through the stuff you've written. Here's what I'm doing: 1. I placed log4j-1.2.8.jar in WEB-INF/lib 2. I placed log4j.properties in WEB-INF/classes 3. I deployed the application on JBoss 3.2.1 By default, JBoss has log4j.jar in jboss/lib which is in my classpath. So, even my application class loader takes the classes from log4j.jar located in jboss/lib? If I remove log4j.jar in jboss/lib, then I think I will not get server log of JBoss. How to solve this issue? Please inform. Sriram -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:00 AM To: Log4J Users List Subject: RE: Log file location Hi Sriram, Do you have log4j.jar in WEB-INF/lib? If not, I'd expect default initialization not to work. Remember that the webapp class loader can see parent class loaders, but the parents cannot see the webapp class loader, hence your log4j.properties will definitely not be found. If you are trying to use log4j.jar in a parent class loader and want your own configuration file to be used in your own logging space, then you will need to use a repository selector. See the log4j-sandbox for working examples. I wrote something up about this stuff here...
Re: config file reloading
Jake, Thanks for the input and warnings! I can't use the -D option when starting tomcat because each webapp (~20 of them) will each have a separate configuration file. And the InitContextListener() will only work for my webapps, but not my standalone apps. So it would seem that the best approach is to roll my own, and have something that can be called either from an init servlet or main depending on the app tyoe. --- thanks --- Larry At 06:26 PM 8/27/03 -0500, you wrote: Oh, and I forgot to mention setting the -Dlog4j.configuration system property which you can poll to find where log4j.xml exists. Jake At 06:09 PM 8/27/2003 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake At 03:48 PM 8/27/2003 -0700, you wrote: Hello, I was planning on using the FileWatchdog class (via DOMConfigurator) to cause my log4j.xml file to be reloaded whenever it is changed, avoiding having to bounce the webapp during debug. My problem is that I rely on the default initialization mechanism in log4j to find the file, so I don't have the filename. I'm currently looking at modifying the dtd to add a watch option so the DOMConfigurator can setup the watchdog during init. Is there a better way to do this?? I'm building a package for use by our web-apps and standalone-apps, so I need something that works well in both environments. Any thoughts?? --- regards --- Larry -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
Jake, A quick question about your past use of configureAndWatch() ... I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration additivity, but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file. But in looking through the configureAndWatch() path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config. So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks. --- regards --- Larry At 06:09 PM 8/27/03 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
Unfortunately, I don't have much to say here. I only ever added loggers. A better approach is to use a runtime logger configurator. There is one in the sandbox, but that only works on existing loggers. There are other runtime configurators out there that can add/remove loggers and appenders. All I can say is that configureAndWatch() has issues which you'll have to live with for now. Mark Womack is/was working on a replacement for configureAndWatch() which will be much more flexible and workable (so he says). You might want to get the skinny from him about this new functionality which will be available in Log4j-1.3 when it comes out. Jake At 08:58 AM 8/28/2003 -0700, you wrote: Jake, A quick question about your past use of configureAndWatch() ... I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration additivity, but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file. But in looking through the configureAndWatch() path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config. So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks. --- regards --- Larry At 06:09 PM 8/27/03 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
Two short comments. 1) My name is Ceki not Ciki. 2) You can use LogManager.resetConfiguration() to reset or clear the existing config before you read the new config file. HTH, At 08:58 AM 8/28/2003 -0700, Larry Young wrote: Jake, A quick question about your past use of configureAndWatch() ... I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration additivity, but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file. But in looking through the configureAndWatch() path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config. So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks. --- regards --- Larry At 06:09 PM 8/27/03 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
At 06:16 PM 8/28/2003 +0200, you wrote: Two short comments. 1) My name is Ceki not Ciki. Sorry Ceki, typo. 2) You can use LogManager.resetConfiguration() to reset or clear the existing config before you read the new config file. Ah, yes. Never bothered with that since the configuration I do is totally separated from the rest of the code in the app and using a runtime utility for changing existing loggers is generally all I ever need. Jake HTH, At 08:58 AM 8/28/2003 -0700, Larry Young wrote: Jake, A quick question about your past use of configureAndWatch() ... I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration additivity, but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file. But in looking through the configureAndWatch() path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config. So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks. --- regards --- Larry At 06:09 PM 8/27/03 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: embedding chainsaw or logfactor5
Hi Ricardo, On Thu, 2003-08-28 at 19:58, Ricardo Trindade wrote: Hi, I'm using logfactor5, and I'm wondering if it's possible to embed the logfactor5 or chainsaw swing panel inside my application. I can speak for Chainsaw, as one of the developers of it, I'll defer to someone else with more LF5 experience to comment on it. Depends what you mean by embed? What did you have in mind? I'm also wondering if it's possible to use SocketHubAppender with chainsaw/lf5 with the 1.2.8 release. To be honest I can't remember what Chainsaw does in the 1.2.8 version! (and I'm one of the Chainsaw developers.) I'm not sure it can, I think it was more of an accepting-connections style, rather than making connections. The latest version in CVS certainly can, it does via the Receiver concept. There is a SocketHubReceiver that can be configured which effectively creates connections to your SocketHubAppender (there should be complimentary Receiver's for each network based Appender in the latest CVS). I'd recommend trying out the latest CVS HEAD version where Chainsaw v2 is currently on the back straight for completion, it's very stable (been using it myself for months). Try checking out the jakarta-log4j module from CVS, and running ant chainsaw (copy the build.properties.sample to suit your needs) cheers, Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: config file reloading
Ceki, At 06:16 PM 8/28/03 +0200, you wrote: Two short comments. 1) My name is Ceki not Ciki. apologies ... mea culpa!! 2) You can use LogManager.resetConfiguration() to reset or clear the existing config before you read the new config file. I think that is exactly what I was looking for! I thought I had seen something about it somewhere in my travels, but I couldn't remember where. Thanks. --- regards --- Larry HTH, At 08:58 AM 8/28/2003 -0700, Larry Young wrote: Jake, A quick question about your past use of configureAndWatch() ... I noticed in Ciki's book that when loading a config file, only those parts of the existing configuration which are explicitly mentioned in the new config file are affected. That makes sense if you are interested in configuration additivity, but if you are simply trying to maintain the configuration of the running system in-sync with the configuration file, then this would be a bad thing. Not only that, but some loggers who share an appender may get effectively disabled if that appender is reconfigured and the logger is not explicitly in the updated config file. But in looking through the configureAndWatch() path of execution, I don't see them attempting to completely cleanout the current configuration and replace it with the new one specified by the config file. In this situation, I would think it was necessary to blow everything away and start again with the new config. So, how did you deal with this when you were using this feature? Did you have to ensure that loggers were never removed from the config file when it was updated?? Did you make some other mods to ensure consistency?? Any insights or experiences appreciated! Thanks. --- regards --- Larry At 06:09 PM 8/27/03 -0500, you wrote: I used to use the configureAndWatch() method in my webapps, but I advise against it now. The watchdog classes currently have no lifecycle control. LogManager.shutdown() will *not* end the thread that the watchdog uses. If you try to reload your servlet context, the thread will continue to reference the old webapp class loader. Log4j-1.3. should have better options than configureAndWatch(). I would suggest not doing anything to the dtd or DOMConfigurator to provide special support for configureAndWatch(). It will probably be either deprecated or implemented differently later. That said, if you still want to use configureAndWatch(), you can use the InitContextListener() from log4j-sandbox to provide information to your webapp as to where your configuration file is. There are other options as well, but I'll let you read about those. As for dealing with a non-servlet environment, this is actually less problematic since it probably is the only app running under the JVM, unlike a container environment where lots of apps and lots of class loaders are running. I would just provide configuration option for your standalone app to be able to specify where the log4j.xml file exists. Shouldn't be hard to write. And you'll have to do initialization yourself instead of counting on default initialization. Jake -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
