Logger.setLevel()
Hi !
I have this code source :
public class TestLogging
{
Logger mLoggerRoot = Logger.getRootLogger();
Logger mClassLogger = Logger.getLogger(TestLogging.class.getName());
Logger mClassLoggerSoon =
Logger.getLogger(TestLogging.class.getName() + .soon);
public void levelInheritance()
{
// init
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(init : Level of + mClassLogger.getName() +
: + mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(init : Level of +
mClassLoggerSoon.getName() + : + mClassLoggerSoon.getEffectiveLevel());
// mClassLoggerSoon.setLevel(Level.FATAL); // try once with this
line uncommented and once again commented
mClassLogger.setLevel(Level.FATAL);
mLoggerRoot.fatal(1. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(Level of + mClassLoggerSoon.getName() + :
+ mClassLoggerSoon.getEffectiveLevel());
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(2. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(Level of + mClassLoggerSoon.getName() + :
+ mClassLoggerSoon.getEffectiveLevel());
}
public static void main(String args[])
{
TestLogging lTestLogging = new TestLogging();
lTestLogging.levelInheritance();
}
}
Then you have :
root.levelInheritance [01 août 2003 15:42:43,587] 0
(TestLogging.java:112) main FATAL : init : Level of TestLogging : DEBUG
root.levelInheritance [01 août 2003 15:42:43,597] 10
(TestLogging.java:113) main FATAL : init : Level of TestLogging.soon : DEBUG
root.levelInheritance [01 août 2003 15:42:43,597] 10
(TestLogging.java:117) main FATAL : 1. Level of TestLogging : FATAL
root.levelInheritance [01 août 2003 15:42:43,597] 10
(TestLogging.java:118) main FATAL : Level of TestLogging.soon : FATAL
root.levelInheritance [01 août 2003 15:42:43,627] 40
(TestLogging.java:121) main FATAL : 2. Level of TestLogging : DEBUG
root.levelInheritance [01 août 2003 15:42:43,627] 40
(TestLogging.java:122) main FATAL : Level of TestLogging.soon : DEBUG --
1. when we set TestLogging to level FATAL i think it is normal that
TestLogging.soon become FATAL too,
because it is not possible for a logger to have his level 'lower' than
his ancestor.
(So, for this case, it was not possible that level of TestLogging was
FATAL and level of TestLogging.soon was DEBUG)
2. when we set TestLogging to level DEBUG i don't think it is normal
that mClassLoggerSoon become DEBUG too,
because it IS possible for a logger to have his level 'higher' than his
ancestor.
(So, for this case, it was not possible that level of TestLogging was
DEBUG and level of TestLogging.soon was FATAL)
My question :
-
Can you explain to me why in the case 2., level of TestLogging.soon
become DEBUG and doesn't keep its level FATAL.
Notice :
if you uncomment the line mClassLoggerSoon.setLevel(Level.FATAL);,
there is no problem...
root.levelInheritance [01 août 2003 15:39:30,379] 0
(TestLogging.java:112) main FATAL : init : Level of TestLogging : DEBUG
root.levelInheritance [01 août 2003 15:39:30,389] 10
(TestLogging.java:113) main FATAL : init : Level of TestLogging.soon : DEBUG
root.levelInheritance [01 août 2003 15:39:30,389] 10
(TestLogging.java:118) main FATAL : 1. Level of TestLogging : FATAL
root.levelInheritance [01 août 2003 15:39:30,389] 10
(TestLogging.java:119) main FATAL : Level of TestLogging.soon : FATAL
root.levelInheritance [01 août 2003 15:39:30,449] 70
(TestLogging.java:122) main FATAL : 2. Level of TestLogging : DEBUG
root.levelInheritance [01 août 2003 15:39:30,449] 70
(TestLogging.java:123) main FATAL : Level of TestLogging.soon : FATAL
-- NOW THIS IS NORMAL
Thank you
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logger.setLevel()
Your hierarchy looks like this:
root
|-- TestLogging
|-- soon
Messages logged against soon will be level-tested as follows:
1) The level explicitly set on the soon node, if one;
2) If none, the level explicitly set on the TestLogging node, if one;
3) If none, the level explicitly set on root, if one, or else root's default
The important point is that a logger's level is either the level explicity
set on the logger, or the level of the node closest to it in the hierarchy
with an explicitly set level. In your test, you explicitly set a level on
TestLogging, but not on soon; thus messages sent to thhe soon logger
will be checked against that explicitly set level.
1. when we set TestLogging to level FATAL i think it is normal that
TestLogging.soon become FATAL too,
As long as you are not explicitly setting a level on TestLogging.soon, this
is correct; it will inherit the level of its ancestor. And this is what
happens in your test.
because it is not possible for a logger to have his level 'lower' than
his ancestor.
(So, for this case, it was not possible that level of TestLogging was
FATAL and level of TestLogging.soon was DEBUG)
As your own tests show, this is an incorrect assumption... Consider a
typically use-case. Say I have a util package with a bunch of utility
classes. I do not want to see logging from this package normally, so I set
the level on that package to FATAL (or maybe even OFF). However, a class in
that package has recently been giving me trouble (or I want to optimize it,
etc), so I want to kick the level for that class alone down to DEBUG. That
way all messages from that particular class will log at the DEBUG level (so
I can see what's going on internally) but all other classes in that package
continue to log at FATAL (so they don't clutter my logs).
2. when we set TestLogging to level DEBUG i don't think it is normal
that mClassLoggerSoon become DEBUG too,
because it IS possible for a logger to have his level 'higher' than his
ancestor.
(So, for this case, it was not possible that level of TestLogging was
DEBUG and level of TestLogging.soon was FATAL)
Again, you have never explicitly set the level of the soon node, and so it
is simply inheriting the level of its ancestor.
Consider a stripped-down paraphrase of you test...
As posted:
// init
mClassLogger.setLevel(Level.DEBUG);
init : Level of TestLogging : DEBUG
init : Level of TestLogging.soon : DEBUG
// mClassLoggerSoon.setLevel(Level.FATAL);
mClassLogger.setLevel(Level.FATAL);
Level of TestLogging : FATAL
Level of TestLogging.soon : FATAL
mClassLogger.setLevel(Level.DEBUG);
Level of TestLogging : DEBUG
Level of TestLogging.soon : DEBUG
Explicitly setting level on soon logger (what should happen):
// init
mClassLogger.setLevel(Level.DEBUG);
init : Level of TestLogging : DEBUG
init : Level of TestLogging.soon : DEBUG
mClassLoggerSoon.setLevel(Level.FATAL); // - uncommented
mClassLogger.setLevel(Level.FATAL);
Level of TestLogging : FATAL
Level of TestLogging.soon : FATAL
mClassLogger.setLevel(Level.DEBUG);
Level of TestLogging : DEBUG
Level of TestLogging.soon : FATAL
-Original Message-
From: Laurent Delaforge [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:19 AM
To: [EMAIL PROTECTED]
Subject: Logger.setLevel()
Hi !
I have this code source :
public class TestLogging
{
Logger mLoggerRoot = Logger.getRootLogger();
Logger mClassLogger = Logger.getLogger(TestLogging.class.getName());
Logger mClassLoggerSoon =
Logger.getLogger(TestLogging.class.getName() + .soon);
public void levelInheritance()
{
// init
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(init : Level of + mClassLogger.getName() +
: + mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(init : Level of +
mClassLoggerSoon.getName() + : + mClassLoggerSoon.getEffectiveLevel());
// mClassLoggerSoon.setLevel(Level.FATAL); // try once with this
line uncommented and once again commented
mClassLogger.setLevel(Level.FATAL);
mLoggerRoot.fatal(1. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(Level of + mClassLoggerSoon.getName() + :
+ mClassLoggerSoon.getEffectiveLevel());
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(2. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(Level of + mClassLoggerSoon.getName() + :
+ mClassLoggerSoon.getEffectiveLevel());
}
public static void main(String args[])
{
TestLogging lTestLogging = new TestLogging();
lTestLogging.levelInheritance();
}
}
Then you have :
root.levelInheritance [01 août 2003 15:42:43,587] 0
(TestLogging.java:112) main FATAL : init : Level of TestLogging : DEBUG
root.levelInheritance [01 août
RE: Logger.setLevel()
Thank you for your answer which is perfectly clear.
Now I understand the stupidity of my question : i hadn't understand the
basis of the logger's level in a hierarchy !
Steve Ebersole wrote:
Your hierarchy looks like this:
root
|-- TestLogging
|-- soon
Messages logged against soon will be level-tested as follows:
1) The level explicitly set on the soon node, if one;
2) If none, the level explicitly set on the TestLogging node, if one;
3) If none, the level explicitly set on root, if one, or else root's
default
The important point is that a logger's level is either the level
explicity
set on the logger, or the level of the node closest to it in the
hierarchy
with an explicitly set level. In your test, you explicitly set a
level on
TestLogging, but not on soon; thus messages sent to thhe soon
logger
will be checked against that explicitly set level.
1. when we set TestLogging to level FATAL i think it is normal that
TestLogging.soon become FATAL too,
As long as you are not explicitly setting a level on TestLogging.soon,
this
is correct; it will inherit the level of its ancestor. And this is what
happens in your test.
because it is not possible for a logger to have his level 'lower' than
his ancestor.
(So, for this case, it was not possible that level of TestLogging was
FATAL and level of TestLogging.soon was DEBUG)
As your own tests show, this is an incorrect assumption... Consider a
typically use-case. Say I have a util package with a bunch of utility
classes. I do not want to see logging from this package normally, so
I set
the level on that package to FATAL (or maybe even OFF). However, a
class in
that package has recently been giving me trouble (or I want to
optimize it,
etc), so I want to kick the level for that class alone down to DEBUG.
That
way all messages from that particular class will log at the DEBUG
level (so
I can see what's going on internally) but all other classes in that
package
continue to log at FATAL (so they don't clutter my logs).
2. when we set TestLogging to level DEBUG i don't think it is normal
that mClassLoggerSoon become DEBUG too,
because it IS possible for a logger to have his level 'higher' than
his
ancestor.
(So, for this case, it was not possible that level of TestLogging was
DEBUG and level of TestLogging.soon was FATAL)
Again, you have never explicitly set the level of the soon node, and
so it
is simply inheriting the level of its ancestor.
Consider a stripped-down paraphrase of you test...
As posted:
// init
mClassLogger.setLevel(Level.DEBUG);
init : Level of TestLogging : DEBUG
init : Level of TestLogging.soon : DEBUG
// mClassLoggerSoon.setLevel(Level.FATAL);
mClassLogger.setLevel(Level.FATAL);
Level of TestLogging : FATAL
Level of TestLogging.soon : FATAL
mClassLogger.setLevel(Level.DEBUG);
Level of TestLogging : DEBUG
Level of TestLogging.soon : DEBUG
Explicitly setting level on soon logger (what should happen):
// init
mClassLogger.setLevel(Level.DEBUG);
init : Level of TestLogging : DEBUG
init : Level of TestLogging.soon : DEBUG
mClassLoggerSoon.setLevel(Level.FATAL); // - uncommented
mClassLogger.setLevel(Level.FATAL);
Level of TestLogging : FATAL
Level of TestLogging.soon : FATAL
mClassLogger.setLevel(Level.DEBUG);
Level of TestLogging : DEBUG
Level of TestLogging.soon : FATAL
-Original Message-
From: Laurent Delaforge [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:19 AM
To: [EMAIL PROTECTED]
Subject: Logger.setLevel()
Hi !
I have this code source :
public class TestLogging
{
Logger mLoggerRoot = Logger.getRootLogger();
Logger mClassLogger = Logger.getLogger(TestLogging.class.getName());
Logger mClassLoggerSoon =
Logger.getLogger(TestLogging.class.getName() + .soon);
public void levelInheritance()
{
// init
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(init : Level of + mClassLogger.getName() +
: + mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(init : Level of +
mClassLoggerSoon.getName() + : +
mClassLoggerSoon.getEffectiveLevel());
// mClassLoggerSoon.setLevel(Level.FATAL); // try once with this
line uncommented and once again commented
mClassLogger.setLevel(Level.FATAL);
mLoggerRoot.fatal(1. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
mLoggerRoot.fatal(Level of + mClassLoggerSoon.getName() + :
+ mClassLoggerSoon.getEffectiveLevel());
mClassLogger.setLevel(Level.DEBUG);
mLoggerRoot.fatal(2. Level of + mClassLogger.getName() + :
+ mClassLogger.getEffectiveLevel());
RE: Picking up wrong properties file in Weblogic
Well, I seem to have really hit a brick wall on this one. I turned log4j.debug on and got: log4j: Trying to find [log4j.properties] using [EMAIL PROTECTED] class loader. log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource(). log4j: Could not find resource: [log4j.properties]. I've verified that the properties file is in the war file's WEB-INF/classes directory. There are no log4j.properties files in the classpath anywhere. I am using Weblogic 7.0. I wonder if this might have something to do with using a managed server. Maybe I'll ask BEA. -Original Message- From: Steve Ebersole [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:52 PM To: Log4J Users List Subject: RE: Picking up wrong properties file in Weblogic Does this mean its not finding the properties file? Yes So the file is named log4j.properties or log4j.xml and is located in the war's WEB-INF/classes directory? That's strange, it should find it. Have you tried with log4j.debug set to true? You can try placing log4j.jar and the config file in the ear's root and include manifest Class-Path entries in the manifest of the included wars and ejb-jars. Thats what I do, so I know that works. Also, which version of weblogic. I'm using 6.1sp4, and its worked fine for me. Wasn't their a version where weblogic was using log4j? Maybe 7.x? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:33 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The directory was in the system classpath. I took it out, and now I get a No appenders could be found for category (root). message. Does this mean its not finding the properties file? To answer the other questions, this is a Struts application, and I'm in an Action class in the war file. I haven't gotten to logging in the EJB jar file yet. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Is that directory on the classpath somewhere higher than the weblogic app classloader? For example is it on the system classpath or server classpath? Where is the class which triggers log4j initialization? Is it contain within the war file? If, for example, and ejb component is the first to reference log4j, it would not be able to see the stuff in the WEB-INF/classes directory. What else is inside the ear file? Is everything in the ear supposed to share that log4j config? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:48 PM To: '[EMAIL PROTECTED]' Subject: Picking up wrong properties file in Weblogic I have deployed an application as an ear file to Weblogic. The war file within the ear file contains the log4j.properties file in the WEB-INF/classes directory, and the log4j.jar in the WEB-INF/lib directory. My understanding is that log4j should pick up the log4j.properties file from the WEB-INF/classes directory by default. However, my application, for some unknown reason, is picking up a log4j.properties file from elsewhere on my machine...from a directory that contains a Java application that has not been deployed. Anybody know why log4j would be going outside the web app to pick up another properties file? - 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] - 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: Picking up wrong properties file in Weblogic
The problem is that it is using the java jvm class-loader [using [EMAIL PROTECTED] There is a class either in your system or server class-path attempting to initialize log4j prior to your Struts stuff. Once in a web-app or enterprise-app, the class loader would be something named WLContextClassLoader (I forgot the exact class name, but its a bea supplied class). Are you defining anything in the system or server class-path which uses log4j (or even commons-logging)? That would be a problem in weblogic. Even to the point of security realms. I had to end up removing all log4j usage from our custom security realm beacause it got initialized before any apps (and because weblogic loads all sec-realm classes on using the jvm class-loader). You pretty much have two options... 1) Seek out all libraries using either log4j/commons-logging and moving them from the server class-path to the appropriate app-specific directory. 2) Place your log4j.properties file also in the system/server class-path. Note that just about everthing from the jakarta uses either one of these two logging libraries... -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 7:39 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Well, I seem to have really hit a brick wall on this one. I turned log4j.debug on and got: log4j: Trying to find [log4j.properties] using [EMAIL PROTECTED] class loader. log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource(). log4j: Could not find resource: [log4j.properties]. I've verified that the properties file is in the war file's WEB-INF/classes directory. There are no log4j.properties files in the classpath anywhere. I am using Weblogic 7.0. I wonder if this might have something to do with using a managed server. Maybe I'll ask BEA. -Original Message- From: Steve Ebersole [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:52 PM To: Log4J Users List Subject: RE: Picking up wrong properties file in Weblogic Does this mean its not finding the properties file? Yes So the file is named log4j.properties or log4j.xml and is located in the war's WEB-INF/classes directory? That's strange, it should find it. Have you tried with log4j.debug set to true? You can try placing log4j.jar and the config file in the ear's root and include manifest Class-Path entries in the manifest of the included wars and ejb-jars. Thats what I do, so I know that works. Also, which version of weblogic. I'm using 6.1sp4, and its worked fine for me. Wasn't their a version where weblogic was using log4j? Maybe 7.x? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:33 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The directory was in the system classpath. I took it out, and now I get a No appenders could be found for category (root). message. Does this mean its not finding the properties file? To answer the other questions, this is a Struts application, and I'm in an Action class in the war file. I haven't gotten to logging in the EJB jar file yet. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Is that directory on the classpath somewhere higher than the weblogic app classloader? For example is it on the system classpath or server classpath? Where is the class which triggers log4j initialization? Is it contain within the war file? If, for example, and ejb component is the first to reference log4j, it would not be able to see the stuff in the WEB-INF/classes directory. What else is inside the ear file? Is everything in the ear supposed to share that log4j config? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:48 PM To: '[EMAIL PROTECTED]' Subject: Picking up wrong properties file in Weblogic I have deployed an application as an ear file to Weblogic. The war file within the ear file contains the log4j.properties file in the WEB-INF/classes directory, and the log4j.jar in the WEB-INF/lib directory. My understanding is that log4j should pick up the log4j.properties file from the WEB-INF/classes directory by default. However, my application, for some unknown reason, is picking up a log4j.properties file from elsewhere on my machine...from a directory that contains a Java application that has not been deployed. Anybody know why log4j would be going outside the web app to pick up another properties file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
RE: Picking up wrong properties file in Weblogic
Bummer. I think I'm in trouble, then. The app is going to be running on a common server with several other apps that use log4j. In fact, our company's common error handling component is based on log4j. I'm going to have to do some work with our server guys on this one. Thanks for your help. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 8:50 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The problem is that it is using the java jvm class-loader [using [EMAIL PROTECTED] There is a class either in your system or server class-path attempting to initialize log4j prior to your Struts stuff. Once in a web-app or enterprise-app, the class loader would be something named WLContextClassLoader (I forgot the exact class name, but its a bea supplied class). Are you defining anything in the system or server class-path which uses log4j (or even commons-logging)? That would be a problem in weblogic. Even to the point of security realms. I had to end up removing all log4j usage from our custom security realm beacause it got initialized before any apps (and because weblogic loads all sec-realm classes on using the jvm class-loader). You pretty much have two options... 1) Seek out all libraries using either log4j/commons-logging and moving them from the server class-path to the appropriate app-specific directory. 2) Place your log4j.properties file also in the system/server class-path. Note that just about everthing from the jakarta uses either one of these two logging libraries... -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 7:39 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Well, I seem to have really hit a brick wall on this one. I turned log4j.debug on and got: log4j: Trying to find [log4j.properties] using [EMAIL PROTECTED] class loader. log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource(). log4j: Could not find resource: [log4j.properties]. I've verified that the properties file is in the war file's WEB-INF/classes directory. There are no log4j.properties files in the classpath anywhere. I am using Weblogic 7.0. I wonder if this might have something to do with using a managed server. Maybe I'll ask BEA. -Original Message- From: Steve Ebersole [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:52 PM To: Log4J Users List Subject: RE: Picking up wrong properties file in Weblogic Does this mean its not finding the properties file? Yes So the file is named log4j.properties or log4j.xml and is located in the war's WEB-INF/classes directory? That's strange, it should find it. Have you tried with log4j.debug set to true? You can try placing log4j.jar and the config file in the ear's root and include manifest Class-Path entries in the manifest of the included wars and ejb-jars. Thats what I do, so I know that works. Also, which version of weblogic. I'm using 6.1sp4, and its worked fine for me. Wasn't their a version where weblogic was using log4j? Maybe 7.x? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:33 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The directory was in the system classpath. I took it out, and now I get a No appenders could be found for category (root). message. Does this mean its not finding the properties file? To answer the other questions, this is a Struts application, and I'm in an Action class in the war file. I haven't gotten to logging in the EJB jar file yet. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Is that directory on the classpath somewhere higher than the weblogic app classloader? For example is it on the system classpath or server classpath? Where is the class which triggers log4j initialization? Is it contain within the war file? If, for example, and ejb component is the first to reference log4j, it would not be able to see the stuff in the WEB-INF/classes directory. What else is inside the ear file? Is everything in the ear supposed to share that log4j config? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:48 PM To: '[EMAIL PROTECTED]' Subject: Picking up wrong properties file in Weblogic I have deployed an application as an ear file to Weblogic. The war file within the ear file contains the log4j.properties file in the WEB-INF/classes directory, and the log4j.jar in the WEB-INF/lib directory. My understanding is that log4j should pick up the log4j.properties file from the WEB-INF/classes directory by default. However, my application, for some unknown reason, is picking up a log4j.properties
RE: Picking up wrong properties file in Weblogic
You can take a look at the RespoistorySelector stuff that is part of log4j. It is meant to address these kind of scenarios in server deployments. A thread or JNDI based implementation of a RepositorySelector may help you solve this issue -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 8:17 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Bummer. I think I'm in trouble, then. The app is going to be running on a common server with several other apps that use log4j. In fact, our company's common error handling component is based on log4j. I'm going to have to do some work with our server guys on this one. Thanks for your help. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 8:50 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The problem is that it is using the java jvm class-loader [using [EMAIL PROTECTED] There is a class either in your system or server class-path attempting to initialize log4j prior to your Struts stuff. Once in a web-app or enterprise-app, the class loader would be something named WLContextClassLoader (I forgot the exact class name, but its a bea supplied class). Are you defining anything in the system or server class-path which uses log4j (or even commons-logging)? That would be a problem in weblogic. Even to the point of security realms. I had to end up removing all log4j usage from our custom security realm beacause it got initialized before any apps (and because weblogic loads all sec-realm classes on using the jvm class-loader). You pretty much have two options... 1) Seek out all libraries using either log4j/commons-logging and moving them from the server class-path to the appropriate app-specific directory. 2) Place your log4j.properties file also in the system/server class-path. Note that just about everthing from the jakarta uses either one of these two logging libraries... -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 7:39 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Well, I seem to have really hit a brick wall on this one. I turned log4j.debug on and got: log4j: Trying to find [log4j.properties] using [EMAIL PROTECTED] class loader. log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource(). log4j: Could not find resource: [log4j.properties]. I've verified that the properties file is in the war file's WEB-INF/classes directory. There are no log4j.properties files in the classpath anywhere. I am using Weblogic 7.0. I wonder if this might have something to do with using a managed server. Maybe I'll ask BEA. -Original Message- From: Steve Ebersole [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:52 PM To: Log4J Users List Subject: RE: Picking up wrong properties file in Weblogic Does this mean its not finding the properties file? Yes So the file is named log4j.properties or log4j.xml and is located in the war's WEB-INF/classes directory? That's strange, it should find it. Have you tried with log4j.debug set to true? You can try placing log4j.jar and the config file in the ear's root and include manifest Class-Path entries in the manifest of the included wars and ejb-jars. Thats what I do, so I know that works. Also, which version of weblogic. I'm using 6.1sp4, and its worked fine for me. Wasn't their a version where weblogic was using log4j? Maybe 7.x? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:33 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The directory was in the system classpath. I took it out, and now I get a No appenders could be found for category (root). message. Does this mean its not finding the properties file? To answer the other questions, this is a Struts application, and I'm in an Action class in the war file. I haven't gotten to logging in the EJB jar file yet. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Is that directory on the classpath somewhere higher than the weblogic app classloader? For example is it on the system classpath or server classpath? Where is the class which triggers log4j initialization? Is it contain within the war file? If, for example, and ejb component is the first to reference log4j, it would not be able to see the stuff in the WEB-INF/classes directory. What else is inside the ear file? Is everything in the ear supposed to share that log4j config? -Original Message- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:48 PM To: '[EMAIL PROTECTED]' Subject: Picking up wrong
RE: Picking up wrong properties file in Weblogic
At 07:50 AM 8/4/2003 -0500, you wrote: You pretty much have two options... 1) Seek out all libraries using either log4j/commons-logging and moving them from the server class-path to the appropriate app-specific directory. 2) Place your log4j.properties file also in the system/server class-path. There are 2 other options. 1. I'm not sure how Websphere is set up with its classloaders, but if it complies with the servlet spec, the WebappClassLoader should be checked first before any other class loaders. Note this is inverse to the standard Java2 class loader delegation model. You can take advantage of this by putting log4j.jar in WEB-INF/lib of your app. It shouldn't matter one bit whether other apps are using log4j at all unless other libraries in your webapp are performing configuration after you have done your. But you shouldn't have to worry about applications (or the server itself) configuring log4j outside of your webapp. Their default logger repository will be separate from yours. 2. If that doesn't work, then this is guaranteed to work. Use a separate logger repository to log messages for you app. All the other app using log4j are using the default logger repository. If you use a custom logger repository selector to set a distinct logger repository for each app, then none of them will collide. See... http://www.qos.ch/logging/sc.html this might also be helpful... http://www.onjava.com/pub/a/onjava/2003/04/02/log4j_ejb.html For a couple implementations of repository selectors, look here... http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/ Take a look at the InitContextListener to utilize the repository selectors in a webapp... http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/InitContextListener.java Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
