When starting my managed server I see the following ClassCastException related to log4j in my WebLogic 12c managed server out file. I have commons-logging-1.1.1.jar and log4j-1.2.17.jar bundled in my WAR's lib directory and no other version of those libraries there. I also pasted the managed server log file error generated in in processing a request. Should I be using the log4j and commons logging that comes with WebLogic 12c? I see these in the modules directory: com.bea.core.apache.commons.logging_1.1.2.jar and com.bea.core.apache.log4j_1.2.0.0_1-2-15.jar. I haven't had a problem with log4j and WebLogic before.
out file:
jadomain.lang.ClassCastException: org.apache.log4j.RollingFileAppender cannot be cast to org.apache.log4j.Appender
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.jadomain:248)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.jadomain:176)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.jadomain:191)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.jadomain:523)
at org.apache.log4j.xml.DOMConfigurator.parseCategory(DOMConfigurator.jadomain:436)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.jadomain:1004)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.jadomain:872)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.jadomain:778)
at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.jadomain:906)
at com.domain.d.app.restwrapper.ContextListener.contextInitialized(ContextListener.jadomain:37)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.jadomain:66
log file:
]] Root cause of ServletException.
jadomain.lang.LinkageError: loader constraint violation: when resolving method "org.apache.log4j.LogMF.entering(Lorg/apache/log4j/Logger;Ljadomain/lang/String;Ljadomain/lang/String;)V" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the current class, com/domain/d/app/restwrapper/appResource, and the class loader (instance of weblogic/utils/classloaders/GenericClassLoader) for resolved class, org/apache/log4j/LogMF, have different Class objects for the type /lang/String;)V used in the signature
at com.domain.d.app.restwrapper.appResource.addQuery(appResource.jadomain:244)
at com.domain.d.app.restwrapper.appResource.addQuery(appResource.jadomain:224)
at com.domain.d.app.restwrapper.appResource$Proxy$_$$_WeldClientProxy.addQuery(appResource$Proxy$_$$_WeldClientProxy.jadomain)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jadomain:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jadomain:43)
You have a conflict between tow versions of log4j. One is loaded from the server's classpath and the other one from your web application's classpath.
To resolve it you can setup your web application to use only the one from your application. Update your weblogic.xml file and add the following tag :
<prefer-web-inf-classes>true</prefer-web-inf-classes>
Related
My projects look like this
EAR_proj
lib/
3rd party jars
EJB_proj
Web_proj (a web service with WSDL)
Common_proj1
Common_proj2
EAR_proj has Deployment Assembly contains all other projects
All projects have "EAR library" in their classpath for the 3rd party libraries.
The Web_proj has Deployment Assembly contains Common_proj1 and Common_proj2 (in its MANIFEST.MF)
However when I deploy the Web_project to the server (within RAD), I kept getting NoClassDefFoundError for 1 class that resides within Common_proj1.
Looking at WebSphere ffdc error file, it says
FFDC Exception:java.io.FileNotFoundException SourceId:com.ibm.ws.websvcs.utils.Axis2Utils.getApplicationClassPath ProbeId:874
java.io.FileNotFoundException: Common_proj1\bin (Access is denied.)
The other ffdc file indicate Common_proj1/bin is on the classpath of some ClassLoader...I'm not sure why it doesn't just treat Common_proj1 as a jar file. Is it because this happen within the IDE?
The server Classloader policy is set to "Single" and "Classes loaded with parent class loader first" policy
Turn out this is a RAD problem after upgrading to a newer JDK.
http://www-01.ibm.com/support/docview.wss?uid=swg21667356
Adding the attribute wsldLocation in the web service implementation class solves the problem.
I'm deploying an ear to JBoss and when I start the server I get this exception thrown:
Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "ch.qos.logback.classic.LoggerContext.getLogger(Ljava/lang/String;)Lorg/slf4j/Logger;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, ch/qos/logback/classic/LoggerContext, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/slf4j/ILoggerFactory have different Class objects for the type ;)Lorg/slf4j/Logger; used in the signature
I have an EAR project and in the deployment assembly I include logback-classic/logback-core/ and slf4j-api. When I do this, the three jars automatically get placed in the EAR Libraries folder in the build paths of 2 other ejb projects (which are both packaged as jars and referenced in the deployment assembly of the EAR)
not sure why this is happening.. Also, when I dont put the jars in the deployment assembly of the EAR, I link them in the build path of the 2 ejb projects directly, but when I deploy the ear JBoss throws noClassFound exception on slf4j/Logger..
any ideas?
Fixed this issue.. I had to edit my jboss-deployment-structure.xml and add the main deployment with exclusions in addition to the sub-deployments that I had.
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 am developing an application for WebSphere 6.1 which uses a Java servlet. Within my servlet, I have defined a serial vesion ID of 1L. Upon deploying and running my application, I am receiving a LinkageError of the following type (from the server log):
[5/9/11 15:14:26:868 EDT] 0000001c WebApp
E [Servlet Error]-[ManageRecordsConsumerServlet]: java.lang.Exception:
java.lang.LinkageError: LinkageError while defining class:
<redacted>.docindexupdate.batch.servlet.ManageRecordsConsumerServlet
Could not be defined due to: (<redacted>/docindexupdate/batch/servlet
/ManageRecordsConsumerServlet) class name must be a string at offset=2074
This is often caused by having a class defined at multiple
locations within the classloader hierarchy. Other potential causes
include compiling against an older or newer version of the class
that has an incompatible method signature.
I'm not sure what the issue is. I was seeing this previously before defining a serial version uid and figured that by defining that and being consistent, future updates to the class file would run successfully. There are no errors during compilation or deployment to the server. Is it possible that an older version of the servlet is cached somewhere on the WebSphere instance (I am only deploying on my dev machine at the moment)?
The
class name must be a string at offset=2074
line is also confusing.
I am suspecting you have a jar that is being loaded in two different classloaders. By that I mean, your websphere server on startup loads that jar or has an endorsed directory with that jar. Also your EAR you are deploying has that jar in its lib. The two can conflict at runtime
What I would suggest is to find out which jar ManageRecordsConsumerServlet belongs to and either remove it from your EAR lib or your Websphere endorsed lib (best would be your EAR lib).
It may be versioning, but I don't thing so.
When two classes loaded by different classloader, a ClassNotFoundException is normally thrown.
When a class is passed over a wire/loaded from disk cache, VersionMismatchException is normally thrown.
When a class with different method signatures is used, NoSuchMethodError or alike is thrown.
I think this case is a corrupted class file. Could be corrupted in cache or in the JAR.