Struts2 log4j将日志写入文件，但可以写到控制台，为什么？

[imarine]

我现在出现一个情况， 普通控制台运行可以写log到文件，但是Struts中Action里的Logger却不能写log到文件。

为什么呢？

另外，时间模式中 %-d{yyyy-MM-dd HH:mm:ss, SSS}的SSS指什么
就是日志中时间后面的数字，谁知道是什么意思？

附控制台打印的错误信息：
情報: Server startup in 4714 ms
2008-12-24 16:32:08, 776 INFO [http-8080-Processor24] (ActionValidatorManagerFactory.java:29) - Detected AnnotationActionValidatorManager, initializing it...
2008-12-24 16:32:08, 854 ERROR [http-8080-Processor24] (LoginAction.java:23) - into action.
2008-12-24 16:32:09, 556 ERROR [http-8080-Processor24] (LoginAction.java:32) - 001
2008-12-24 16:32:09, 556 ERROR [http-8080-Processor24] (LoginAction.java:33) - username does not exist, please check and input again
2008-12-24 16:32:09, 556 ERROR [http-8080-Processor24] (LoginAction.java:35) - message: username does not exist, please check and input again
Neusoft Intercepter : 3201
2008-12-24 16:32:33, 804 ERROR [http-8080-Processor25] (LoginAction.java:23) - into action.
Neusoft Intercepter : 281
2008/12/24 16:34:05 org.apache.catalina.core.StandardContext reload
情報: このコンテキストの再ロードを開始しました
log4j:ERROR LogMananger.repositorySelector was null likely due to error in class reloading, using NOPLoggerRepository.
2008-12-24 16:34:06, 160 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]] (XmlConfigurationProvider.java:140) - Parsing configuration file [struts-default.xml]
2008-12-24 16:34:06, 316 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]] (XmlConfigurationProvider.java:140) - Parsing configuration file [struts-plugin.xml]
2008-12-24 16:34:06, 363 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]] (XmlConfigurationProvider.java:140) - Parsing configuration file [struts.xml]
2008-12-24 16:34:06, 363 WARN [ContainerBackgroundProcessor[StandardEngine[Catalina]]] (Settings.java:143) - Settings: Could not parse struts.locale setting, substituting default VM locale
2008-12-24 16:34:07, 112 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]] (ObjectTypeDeterminerFactory.java:28) - Setting DefaultObjectTypeDeterminer as default ...

[imarine]

以下，好像是说是Tomcat和Log4j协作的问题。

List: log4j-user
Subject: Re: LogMananger.repositorySelector was null
From: Curt Arnold <carnold () apache ! org>
Date: 2008-04-23 17:03:28
Message-ID: 6D42962C-5DB1-4ACB-BB3A-D9D0D91E9B0B () apache ! org
[Download message RAW]


On Apr 23, 2008, at 9:59 AM, hezjing wrote:

> Hi
>
> My web-based application is using log4j release 1.2.15 and running on
> Tomcat 5.5 (as a Windows service).
> When I stopped the Tomcat service, the following error is printed in
> stdout_20080423.log
>
> log4j:ERROR LogMananger.repositorySelector was null likely due to
> error in class reloading, using NOPLoggerRepository.
>
>
> What does this means?
>

Certain versions of Tomcat with certain configurations can leave log4j
in a corrupted state that is unreachable by normal language means as
the Tomcat classloader will set to null private static members in
order to prevent a class of memory leaks. It would be fine if that
only occurred after the class was no longer used, but in some poorly
defined instances, log4j will still be referenced after the Tomcat
classloader plays with it. The error indicates that a log request was
attempted after Tomcat played with it. Prior to log4j 1.2.15, that
would result in a NullPointerException. In log4j 1.2.15 and later, it
results in this error message and all subsequent logging requests are
discarded. If this happens only on shutdown, you may not have missed
anything.

For more background than you probably want, see the Tomcat and log4j
bugs:

http://issues.apache.org/bugzilla/show_bug.cgi?id=41939
http://issues.apache.org/bugzilla/show_bug.cgi?id=40212
http://issues.apache.org/bugzilla/show_bug.cgi?id=43867