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.
Related
I am getting the following error:
ERROR StatusLogger Log4j2 could not find a logging implementation.
Please add log4j-core to the classpath. Using SimpleLogger to log to
the console.
I am using eclipse V4.3.2 in a GWT application.
Both log4j-api-2.4.1.jar and log4j-core-2.4.1.jar are on the class path.
I've seen other postings similar to my error but it's not clear to me what I am doing wrong if anything.
Thanks
Classpath is not enough (and actually wrong), you need server code within the WAR's WEB-INF (WEB-INF/lib to be exact here).
I'm having an issue I believe is due to Tomcat, but I'm not sure where to go because I'm not too knowledgeable on the subject
The problem is, I have a couple of projects that use log4j, and recently when starting the server I get the following error:
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [org.apache.catalina.loader.StandardClassLoader#a9ae05] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by [WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
Doing some reading, I saw it pointed out that this was due to having several copies of the same jar.
Now, I believe that this is Tomcat's fault. I made a second server in Eclipse and the new server boots fine, so that sounds like a problem with the server configuration in the messed up one.
So I assume my old Tomcat is loading a jar file and this causes a conflict, whereas the new one doesn't have this jar file to cause the conflict in its configurations? My question is; how do I go about finding the culprit jar or configuration error?
When I am deploying my war file in Jboss 5.1 , I am getting:
ERROR [STDERR] log4j:ERROR A "org.jboss.logging.appender.FileAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
ERROR [STDERR] log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
ERROR [STDERR] log4j:ERROR [BaseClassLoader#18c1f7d{vfszip:/C:/jboss-5.1.0.GA/server/default/deploy/OnlineUsage.war/}] whereas object of type
ERROR [STDERR] log4j:ERROR "org.jboss.logging.appender.FileAppender" was loaded by [org.jboss.bootstrap.NoAnnotationURLClassLoader#291aff].
ERROR [STDERR] log4j:ERROR Could not instantiate appender named "FILE".
Even with the above error , I can hit the ?wsdl URL correctly.
Next I tried simply by deleting the log4j jar file from war and deployed successfully without any error. Got ?wsdl correctly too.
My question is whether this will create problem in production or real time(Real time error or binding error).
In the past I got an error Failed to create SAX Parser. If it is not an issue to remove the jar from war, can I remove XercesImpl jar also? Since Jboss has its own jar files, I can avoid Class cast-exceptions.
In order to avoid class casting exception, I would highly recommend not packaging any JBoss or JDK provided jars in your WEB-INF/lib folder. If you have to for some reason, the utilize class loading isolation with jboss-classloading.xml file.
This principle holds true for other Java EE containers (Websphere, Weblogic, GlassFish, etc) as well. You never want to package JDK and container provided libraries in your own artifact.
You can make use JBoss Tattletale which is a great open source tool to find out what dependencies to not package in WAR/EAR.
I have a .jar file added to the CLASSPATH of the JBoss 5 startup (run.bat/run.sh) file. This is a dependency jar which is referred to from the servlet based application. If I use this setup, the servlet loads fine and works as expected. However, I noted that if I have the same jar in the servlet's WEB-INF/lib directory, I get a class cast exception as follows:
ERROR [STDERR] ERROR: com.idoox.wasp.ProtocolRepositoryImpl - Exception in protocolHandler soap, protocolHandler com.server.saaj.soap.SOAP11ProtocolHandler, class space root.wasp-impl.SOAP :
ERROR [STDERR] EXCEPTION:
ERROR [STDERR] com.systinet.saaj.soap.SOAP11ProtocolHandler cannot be cast to org.idoox.wasp.ProtocolHandler
ERROR [STDERR] java.lang.ClassCastException: com.server.saaj.soap.SOAP11ProtocolHandler cannot be cast to org.idoox.wasp.ProtocolHandler
This is not an issue since I won't have the jar in both places, but I'm just wondering why it is happening this way. Is this a class loading issue?
Thank You.
The jar file you are mentioning would be already available with JBoss. Whe you place it in the WEB-INF/lib; JBoss has already loaded the class from the jar available with JBoss and there is conflict with the class in the web-inf folder. Classes loaded by different classloaders are treated as different even if the classes are same. When you give in run.bat there is only one jar file loaded. JBoss loads this and there is no conflicting jars.
I just picked up an existing web application at work that is supposed to log its activity using Log4J. I've configured my workspace exactly as I was told to and everything else (db connection, authentication, etc...) works fine except that the nothing is being written to the log file. Other similar applications have no problem logging.
I've looked at the WebSphere console when the application starts up and there are no errors there that might indicate why Log4J isn't logging.
I mentioned this to another dev (who once worked on this application, but not for a while and is more out of date than I am on it) who remarked that it was very strange behaviour, but had no idea why it might fail to log and not report any errors.
I've gone over the config file and properties file and everything looks OK. I suspect that Log4J is never even reading the log4j.xml but I'm not certain of that. It's been a while since I've worked with Log4J - does anyone have some good tips on trouble-shooting this type of problem?
PS: There are instances of this application that are deployed to various test/QA/prod servers and these instances all log fine. It's only on local workstations that logging seems to silently fail.
Update: So it does seem to be a problem with the way the application is being deployed.
I changed the classloader mode to "Parent Last" and I can see that the Log4J file is at least being read now. And the first action I attempt triggers a ClassNotFoundException saying that org.apache.commons.logging.impl.Log4jFactory cannot be found.
2nd Update:
I've noticed something stranger... The application has two WAR projects - one of them is for the UI and the other is for some web services. The project that is for the UI is successfully logging its operations to the log file. The web service project is the one that fails with the ClassNotFoundException. Both of them have commons-logging.jar listed as a JavaEE module dependency, and neither of them have a project-specific logging configuration (all config files are in a Resources project).
A major difference is that that UI project includes some other in-house frameworks (pre-compiled as JARs) that might already include necessary logging configurations and maybe that's where the difference is.
I also tried to use the answer (a file named org.apache.commons.logging.LogFactory in the META-INF/services with one line containing: "org.apache.commons.logging.impl.Log4jFactory") from this question: Websphere all logs are going to SystemOut.log but it did not seem to help.
See this answer:
How to initialize log4j properly?
-Dlog4j.debug is very useful for problems like this
The most recent thing I changed that finally got logging working properly was changing the classloader mode to "PARENT_FIRST" and WAR classloader policy to "Application". The initial default configuration was "PARENT_FIRST"/"Module". I changed it to "PARENT_LAST"/"Application" on the advice of a co-worker who says logging works fine for them and this is the only change they have to make when they create a new sandbox for this application. I'm not sure why I had to go with "PARENT_FIRST"/"Application", but at least it works now.
UPDATE:
I tried setting up a new workspace and I had the same problem. It turns out you need "PARENT_FIRST"/"Application" AND a file named org.apache.commons.logging.LogFactory in the META-INF/services with one line containing: "org.apache.commons.logging.impl.Log4jFactory". Not having the file causes logging to fail (typically with a message saying that a Log4J cannot be found).
just my two cents - i had something like this happening - but in my case i could see some output from my logging calls. it was just apparent that the configuration was picked up from somewhere else, and the one i was changing didn't have any impact.
after turning on -Dlog4j.debug=true as suggested here, it was evident that log4j was picking up a file named log4j.xml situated inside my tomcat's work directory. either it was a leftover from other stuff i was doing, or it was generated somehow from some log4j configuration in one of my misconfigured libraries.
i haven't thought of erasing the contents of work directory (could have tried.. [edit: i tried and it didn't work]) - the only thing i though of was to pass hardcoded reference to my properties file through -Dlog4j.configuration=log4j.properties (didn't want to use absolute path) (it happened that i was using a properties file and not an xml) - and it worked.
[edit: well, it didn't work for the server configuration. I finally found what was wrong - some home-cooked libraries that I was including as JARs into my project, had their own log4j.xml and log4j.properties files, which were apparently read/found earlier than my own properties file - the rightest thing was to delete these redundant property files from JARs]
I realize this isn't your exact same symptom, but there are known issues with log4j if your application (or anything it uses) uses Commons Logging. See if this question/answer is relevant.
I had a problem where log4j was not showing anything in one of my projects. Turned out I had added a leading space in the classname in the log4j2.xml file. Log4j does a dictionary lookup by classname. So any leading or trailing space in the classname would render that particular entry invalid.
not able to create log file, i have used logback.xml file in spring webservice application and deployed into websphere server...But when i have used log4j.properties file it is creating log file . i have given proper dependency proper for log4j and slf4j.. logback.xml file
<file>C:/abc/myLogFile.log</file>
<append>true</append>
<encoder>
<pattern>%d [%thread] %-5level %logger{35} - %msg%n</pattern>
</encoder></appender>
`
dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>