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 jchi <ja...@telus.com> on 2008/01/03 01:17:44 UTC
Missing or duplicate logging entries using log4j
We have multiple WARs in a EAR. Each of the WARs includes the log4j.jar and
loads its own log4j.properties during the startup of the webapp. With this
setup, each WAR can log into its own log file.
<br>
99% of the time it is working propoerly, but there are sporadic cases where
an entry either does not get logged or get logged twice.
<br>
Has anyone run into this problem?
--
View this message in context: http://www.nabble.com/Missing-or-duplicate-logging-entries-using-log4j-tp14589237p14589237.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Missing or duplicate logging entries using log4j
Posted by Jacob Kjome <ho...@visi.com>.
On Fri, 4 Jan 2008 10:50:36 -0800 (PST)
jchi <ja...@telus.com> wrote:
>
> Hi Jake,
>
> Thanks for the reply. We are running it on the weblogic 9.2.2 server. There
> is no log4j.jar under the APP-INF/lib.
>
Do you have an application level libraries that you want logging for? Where
does it get it get Log4j from? It's either got to be in APP-INF/lib or the
server classpath.
> Each of the webapp picks up its own log4j.properties from the classpath
> during startup.
> E.g. App1 picks up [CLASSPATH]/App1/log4j.properties.
> App2 picks up [CLASSPATH]/App2/log4j.properties
>
When you say "picks up", do you mean it uses Log4j's auto-configuration? If
so, and unless you've specifically configured your app to use child-first
classloading, then the log4j.properties would get picked up from the EAR level
instead of the Webapp level. If you mean that you manually configure, then it
might be possible. Then again, log4j.properties has probably already gone
through auto-configuration prior to this, which could be the source of your
problem. Read on...
> There is a log4j.properties in the EAR level, but it is only used during the
> startup before the proper classpath is constructed.
>
This doesn't make much sense. The classpath will have been properly
constructed at deployment time. I can only take this to mean, as I alluded to
previously, that you use this for EAR level libraries which might get invoked
before webapps get invoked. But in this case, you'd have to have log4j.jar at
the EAR level or the server level. And if it's in either of those places, the
log4j.jar your webapps are using (again, if you haven't specifically
configured webapps to use child-first classloading) is the log4j.jar at the
EAR or server level. What this would mean is that you are using a single
logger repository for all webapps. And if you are performing manual
configuration, you are just reconfiguring the logger repository multiple times
(once per/app).
Actually, any way you look at it (whether or not you are using a single logger
repository at the EAR or server level), you are most likely configuring your
log4j instance(s) multiple times - once via auto-configuration and once via
manual configuration (assuming you are performing manual configuration).
Here's the problem, when you run configure(), the existing configuration in
the logger repository does not get blown away. It gets overlayed. If the
previous configure() added Appender A1 to a logger hierarchy and your new
configuration adds A1 again, you now have two instances of the A1 appender
attached and will end up with 2 messages instead of one.
I'm not sure I can explain the missing entries, but I think the duplicates
make sense.
BTW, why not set the root logger to WARN and then lower the level where needed
on specific libraries. There's probably a lot more libraries that you want to
turn off than turn on.
Jake
> As I said, 99.9% of the time it is working ok, but there are some rare cases
> which an entry is missing or duplicated, like:
>
> 2007.08.04-01:34:16 INFO com.abc.transfer.web.action.TransferAction
> 53115011861912527 [Param: command = transferred]
> 2007.08.04-01:34:16 INFO com.abc.transfer.web.action.TransferAction
> 53115011861912527 [Param: command = transferred]
>
> 2007.08.22-00:29:49 TRACE com.abc.transfer.web.action.TransferAction
> 53172011877425870 [In transferred().]
> 2007.08.22-00:29:49 TRACE com.abc.transfer.web.action.TransferAction
> 53172011877425870 [In transferred().]
>
> I have attached the 2 log4j.properties below:
>
> http://www.nabble.com/file/p14622776/startup-log4j.properties
> startup-log4j.properties
> http://www.nabble.com/file/p14622776/webapp-log4j.properties
> webapp-log4j.properties
>
> Thanks,
> James
> --
> View this message in context:
>http://www.nabble.com/Missing-or-duplicate-logging-entries-using-log4j-tp14589237p14622776.html
> Sent from the Log4j - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Missing or duplicate logging entries using log4j
Posted by jchi <ja...@telus.com>.
Hi Jake,
Thanks for the reply. We are running it on the weblogic 9.2.2 server. There
is no log4j.jar under the APP-INF/lib.
Each of the webapp picks up its own log4j.properties from the classpath
during startup.
E.g. App1 picks up [CLASSPATH]/App1/log4j.properties.
App2 picks up [CLASSPATH]/App2/log4j.properties
There is a log4j.properties in the EAR level, but it is only used during the
startup before the proper classpath is constructed.
As I said, 99.9% of the time it is working ok, but there are some rare cases
which an entry is missing or duplicated, like:
2007.08.04-01:34:16 INFO com.abc.transfer.web.action.TransferAction
53115011861912527 [Param: command = transferred]
2007.08.04-01:34:16 INFO com.abc.transfer.web.action.TransferAction
53115011861912527 [Param: command = transferred]
2007.08.22-00:29:49 TRACE com.abc.transfer.web.action.TransferAction
53172011877425870 [In transferred().]
2007.08.22-00:29:49 TRACE com.abc.transfer.web.action.TransferAction
53172011877425870 [In transferred().]
I have attached the 2 log4j.properties below:
http://www.nabble.com/file/p14622776/startup-log4j.properties
startup-log4j.properties
http://www.nabble.com/file/p14622776/webapp-log4j.properties
webapp-log4j.properties
Thanks,
James
--
View this message in context: http://www.nabble.com/Missing-or-duplicate-logging-entries-using-log4j-tp14589237p14622776.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Missing or duplicate logging entries using log4j
Posted by Jacob Kjome <ho...@visi.com>.
It would help to see your config.
BTW, what server? And are you sure you don't have log4j.jar in the EAR (such as
APP-INF/lib under Weblogic) or in the server's lib directory? Or, there's always
the possibility of a log4j.xml sitting somewhere in the parent classloader and it
is getting picked up in preference to log4j.properties.
Jake
jchi wrote:
> We have multiple WARs in a EAR. Each of the WARs includes the log4j.jar and
> loads its own log4j.properties during the startup of the webapp. With this
> setup, each WAR can log into its own log file.
> <br>
>
> 99% of the time it is working propoerly, but there are sporadic cases where
> an entry either does not get logged or get logged twice.
> <br>
>
> Has anyone run into this problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org