You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Janice <ja...@telus.net> on 2006/01/05 00:45:53 UTC
How to get rid of the zillions of DEBUG messages?
I did have log4j set up on a computer, but then it died and I can't seem to
get my new development environment to behave as well. I'm using log4j 1.2.8
on a struts application, and using an oc4j standalone server for
development. I'm hoping someone would be so kind as to suggest what I'm
missing/doing wrong now.
Here is the contents of my log4j.properties file:
# Create appenders:
log4j.rootLogger=INFO, stdout, F
# Configure the stdout appender <- no need when not in development
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %x - %m%n
# Configure the file appender
log4j.appender.F=org.apache.log4j.RollingFileAppender
# Do not write to application log specified in orion-application.xml
(barts.log)
# as OC4J puts an exclusive lock on this file: attempts to append will fail
log4j.appender.F.File=C:\\WORK\\bart\\barts_log4j.log
log4j.appender.F.MaxFileSize=1MB
log4j.appender.F.MaxBackupIndex=1
log4j.appender.F.layout=org.apache.log4j.PatternLayout
log4j.appender.F.layout.ConversionPattern=%d [%t] %-5p %x - %m%n
# Turn some of the more verbose stuff off, I'm more interested in my logging
log4j.logger.org.apache.commons=warn
log4j.logger.org.apache.struts=warn
But despite the "warns", I get lots of lines like this:
111843 [HttpRequestHandler-3513371] DEBUG
org.apache.struts.tiles.TilesRequestProcessor - '.login' - processed as
definition
or
103718 [HttpRequestHandler-3513371] DEBUG
org.apache.commons.beanutils.ConvertUtils - Convert string 'false' to class
'boolean'
The log4j.properties is located in my \WEB-INF\classes directory.
Thanks for your help!
RE: How to get rid of the zillions of DEBUG messages?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Janice <ja...@telus.net>:
> Hello, and thanks for your reply. My log4j-1.2.8.jar file is in my
> WEB-INF\lib. But it is also in my j2ee\home\lib
As I suspected
>, and if I remove it from
> there I get issues with my JAASUserManager.
Because it uses Log4j. Probably a NoClassDefFoundError, right?
> If I remove it from WEB-INF\lib
> there is no change in its behaviour.
>
Yep, that would be expected as well. It isn't being used at all because there
already exists on in a parent classloader.
> I believe that oc4j is not using child-first classloading.
Clearly
> I found a
> switch: <web-app-class-loader search-local-classes-first="true" />, but when
> I use it then I get other issues with my application and can't get far
> enough to tell whether its fixed the logging.
>
Yes, appservers that don't use child-first classloading, by default, seem to
have problems when enabling it. I think they should just choose to support it
and have it on by default or choose not to suppport it and not have it as an
option because it always seems to be implemented poorly in those cases.
> I tried dropping the log4j.properties file into the j2ee\home\lib and it
> behaves as I'd like now, even though I'm sure that's a rotten way to do it.
Well, it depends. If you are the owner of the server and you control the apps
that go there and whatever logging that occurs, then it isn't so bad. You can
even using something like LogWeb to control logging dynamically on a
server-wide basis via a web interface. If your app is hosted on a server that
hosts other applications that you don't own, then you have a problem. There
are workarounds such as using a logger repository selector to enable separate
logger repositories per/application, even though all apps share the same
instance of Log4j. However, that introduces some complexity. If you aren't
yet familiar with repository selectors, I wouldn't delve into it unless you
find that you really need to. It's not necessarily that hard, there's just
more to learn.
> Question: if I were to use "-Dlog4j.configuration=file", is this a flag I
> add to the line when I start my server? I tried it and the server didn't
> like that, so I wonder where I am to use it?
>
You append it to the command line to start the JVM. Eg...
java -Dlog4j.configuration=file:///path/to/log4j.properties MyServerBootstrapper
Keep in mind that the value for the system variable log4j.configuration needs to
be a valid URL, not just a system file path. In any case, this doesn't buy you
that much since you still get the same system-wide configuration by putting
log4j.properties in the j2ee\home\lib, which may be easier than adding a param
to a startup script.
Jake
> J
>
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Wednesday, January 04, 2006 9:55 PM
> To: Log4J Users List
> Subject: Re: How to get rid of the zillions of DEBUG messages?
>
> You say log4j.properties is in your WEB-INF/classes directory, but where is
> log4j.jar? Is it in WEB-INF/lib? And if so, is your server also set up to
> use child-first classloading behavior like Tomcat is by default? Most
> servers actually *don't* do this by default. It's usually something you
> have to turn on.
>
> Now, even if log4j.jar is in WEB-INF/lib *and* child-first classloading
> behavior is enabled, you are still left in the cold if somewhere there is a
> directory or jar in the classpath that has log4j.xml which is in the
> default package. I think this is about the 20th time this past week or two
> that I've brought this up, but I'll say it again. If you want to use the
> default initialization and you don't want to specify your file via a system
> property provided at the command line upon JVM startup (something like
> -Dlog4j.configuration=file:///path/to/config), which would end up applying
> to every application in the server, then you should use log4j.xml because
> it gets picked up in preference to log4j.properties if both are found on
> the classpath. log4j.xml could even be in a parent classloader and will
> still get used in preference to WEB-INF/classes/log4j.properties when using
> child-first classloading.
>
> Of course, if you aren't using child-first classloading, there's your
> problem right there. Even if you have log4j.jar in WEB-INF/lib and
> log4j.xml in WEB-INF/classes, but you also have log4j.jar in some parent
> classloader, then that instance of log4j will start with the server and
> every webapp under the server will use it rather than log4j.jar in
> WEB-INF/lib. And, of course, automatic initialization will have been
> performed on server startup with a config file that, most likely, is not
> the one in your webapp.
>
> Jake
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: How to get rid of the zillions of DEBUG messages?
Posted by Janice <ja...@telus.net>.
Hello, and thanks for your reply. My log4j-1.2.8.jar file is in my
WEB-INF\lib. But it is also in my j2ee\home\lib, and if I remove it from
there I get issues with my JAASUserManager. If I remove it from WEB-INF\lib
there is no change in its behaviour.
I believe that oc4j is not using child-first classloading. I found a
switch: <web-app-class-loader search-local-classes-first="true" />, but when
I use it then I get other issues with my application and can't get far
enough to tell whether its fixed the logging.
I tried dropping the log4j.properties file into the j2ee\home\lib and it
behaves as I'd like now, even though I'm sure that's a rotten way to do it.
Question: if I were to use "-Dlog4j.configuration=file", is this a flag I
add to the line when I start my server? I tried it and the server didn't
like that, so I wonder where I am to use it?
J
-----Original Message-----
From: Jacob Kjome [mailto:hoju@visi.com]
Sent: Wednesday, January 04, 2006 9:55 PM
To: Log4J Users List
Subject: Re: How to get rid of the zillions of DEBUG messages?
You say log4j.properties is in your WEB-INF/classes directory, but where is
log4j.jar? Is it in WEB-INF/lib? And if so, is your server also set up to
use child-first classloading behavior like Tomcat is by default? Most
servers actually *don't* do this by default. It's usually something you
have to turn on.
Now, even if log4j.jar is in WEB-INF/lib *and* child-first classloading
behavior is enabled, you are still left in the cold if somewhere there is a
directory or jar in the classpath that has log4j.xml which is in the
default package. I think this is about the 20th time this past week or two
that I've brought this up, but I'll say it again. If you want to use the
default initialization and you don't want to specify your file via a system
property provided at the command line upon JVM startup (something like
-Dlog4j.configuration=file:///path/to/config), which would end up applying
to every application in the server, then you should use log4j.xml because
it gets picked up in preference to log4j.properties if both are found on
the classpath. log4j.xml could even be in a parent classloader and will
still get used in preference to WEB-INF/classes/log4j.properties when using
child-first classloading.
Of course, if you aren't using child-first classloading, there's your
problem right there. Even if you have log4j.jar in WEB-INF/lib and
log4j.xml in WEB-INF/classes, but you also have log4j.jar in some parent
classloader, then that instance of log4j will start with the server and
every webapp under the server will use it rather than log4j.jar in
WEB-INF/lib. And, of course, automatic initialization will have been
performed on server startup with a config file that, most likely, is not
the one in your webapp.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to get rid of the zillions of DEBUG messages?
Posted by Jacob Kjome <ho...@visi.com>.
You say log4j.properties is in your WEB-INF/classes directory, but where is
log4j.jar? Is it in WEB-INF/lib? And if so, is your server also set up to
use child-first classloading behavior like Tomcat is by default? Most
servers actually *don't* do this by default. It's usually something you
have to turn on.
Now, even if log4j.jar is in WEB-INF/lib *and* child-first classloading
behavior is enabled, you are still left in the cold if somewhere there is a
directory or jar in the classpath that has log4j.xml which is in the
default package. I think this is about the 20th time this past week or two
that I've brought this up, but I'll say it again. If you want to use the
default initialization and you don't want to specify your file via a system
property provided at the command line upon JVM startup (something like
-Dlog4j.configuration=file:///path/to/config), which would end up applying
to every application in the server, then you should use log4j.xml because
it gets picked up in preference to log4j.properties if both are found on
the classpath. log4j.xml could even be in a parent classloader and will
still get used in preference to WEB-INF/classes/log4j.properties when using
child-first classloading.
Of course, if you aren't using child-first classloading, there's your
problem right there. Even if you have log4j.jar in WEB-INF/lib and
log4j.xml in WEB-INF/classes, but you also have log4j.jar in some parent
classloader, then that instance of log4j will start with the server and
every webapp under the server will use it rather than log4j.jar in
WEB-INF/lib. And, of course, automatic initialization will have been
performed on server startup with a config file that, most likely, is not
the one in your webapp.
Jake
At 03:45 PM 1/4/2006 -0800, you wrote:
>I did have log4j set up on a computer, but then it died and I can't seem to
>get my new development environment to behave as well. I'm using log4j 1.2.8
>on a struts application, and using an oc4j standalone server for
>development. I'm hoping someone would be so kind as to suggest what I'm
>missing/doing wrong now.
>
>Here is the contents of my log4j.properties file:
># Create appenders:
>log4j.rootLogger=INFO, stdout, F
>
># Configure the stdout appender <- no need when not in development
>log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %x - %m%n
>
># Configure the file appender
>log4j.appender.F=org.apache.log4j.RollingFileAppender
># Do not write to application log specified in orion-application.xml
>(barts.log)
># as OC4J puts an exclusive lock on this file: attempts to append will fail
>log4j.appender.F.File=C:\\WORK\\bart\\barts_log4j.log
>log4j.appender.F.MaxFileSize=1MB
>log4j.appender.F.MaxBackupIndex=1
>log4j.appender.F.layout=org.apache.log4j.PatternLayout
>log4j.appender.F.layout.ConversionPattern=%d [%t] %-5p %x - %m%n
>
># Turn some of the more verbose stuff off, I'm more interested in my logging
>log4j.logger.org.apache.commons=warn
>log4j.logger.org.apache.struts=warn
>
>
>But despite the "warns", I get lots of lines like this:
>111843 [HttpRequestHandler-3513371] DEBUG
>org.apache.struts.tiles.TilesRequestProcessor - '.login' - processed as
>definition
>or
>103718 [HttpRequestHandler-3513371] DEBUG
>org.apache.commons.beanutils.ConvertUtils - Convert string 'false' to class
>'boolean'
>
>The log4j.properties is located in my \WEB-INF\classes directory.
>
>Thanks for your help!
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org