I'm creating additional module to already multi-module maven project. And for this one I want everything to be like in other modules(meaning dependencies) just to test hello world, then I'll go do some more complex stuff. And it does 开发者_运维问答print hello world as it should when deployed onto jboss server, but I get some strange error on console, had anyone had similar experience? and how can I fix it? Here it is :
15:48:35,789 ERROR [STDERR] log4j:ERROR A "org.jboss.logging.appender.FileAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
15:48:35,789 ERROR [STDERR] log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
15:48:35,790 ERROR [STDERR] log4j:ERROR [BaseClassLoader@9a8d9b{vfszip:/C:/jboss-5.1.0.GA/server/default/deploy/new-module-0.0.1-SNAPSHOT.war/}] whereas object of type
15:48:35,790 ERROR [STDERR] log4j:ERROR "org.jboss.logging.appender.FileAppender" was loaded by [org.jboss.bootstrap.NoAnnotationURLClassLoader@506411].
15:48:35,790 ERROR [STDERR] log4j:ERROR Could not instantiate appender named "FILE".
Here is the part of Appender xml
http://pastebin.com/X7Dgdrki
First check your <server>/conf/jboss-log4j.xml
for the configuration of the appender named FILE
(and post it here if you can - that may give us more clues).
Further investigation reveals that org.jboss.logging.appender.FileAppender
actually implements the interface org.apache.log4j.Appender
. So this is apparently a classloader conflict. The same class definition (in this case org.apache.log4j.Appender
), when loaded by two different classloaders, counts as two distinct classes for the JVM.
Is log4j.jar included in your war, or in your server/lib directory? If so, you could try removing it and see whether it resolves the issue.
Update: Actually the easiest possible solution is to simply change the type of the appender to org.apache.log4j.FileAppender
in jboss-log4j.xml.
Regarding log4j.jar, what I mean is that if it is present in your war, it (and a copy of org.apache.log4j.Appender
) gets loaded by the war classloader (BaseClassLoader@9a8d9b
in your error message). And this causes the classloader conflict. So if you do not deploy log4j.jar with your war, the error may go away. This is related to Maven only in that the dependency is configured in your pom. For this little experiment, you can simply remove the log4j.jar from your war by hand; if this solves the issue, configure the log4j dependency in your pom as "provided", e.g.:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
<scope>provided</scope>
</dependency>
If log4j.jar is not in your war, it might still be in the server/default/lib directory - please check that and if it is there, try to remove it.
We recently came across this problem. We tried the suggestions above and they did not work. So we handled the problem by replacing all log4j imports with a abstract logging interface (we chose org.apache.commons.logging for this) and removing the log4j from the depdenancies. Then what happens is the actual underlying logging implementation supports whatever JBoss has set. And if we want to move back to Tomcat (without JBoss) we can just add the log4j jar or whatever logger implementation back into the war.
精彩评论