while starting my weblogic(having my app war file containing logback-classic-1.0.1.jar),i am getting below exception.Any suggestion ?
<Sep 9, 2015 9:27:13 AM UTC> <Warning> <Common> <BEA-000632> <Resource Pool "JDBC Data Source-0" shutting down, ignoring 3 resources still in use by applications..>
Exception in thread "Thread-12" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:125)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:468)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:424)
at ch.qos.logback.classic.Logger.log(Logger.java:824)
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.error(SLF4JLocationAwareLog.java:225)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:415)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:114)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.cache.interceptor.CacheInterceptor$1.invoke(CacheInterceptor.java:58)
at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:213)
at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622)
................
at java.lang.Thread.run(Thread.java:701)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:297)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:52)
... 18 more
Exception in thread "Thread-18" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:125)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:468)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:424)
at ch.qos.logback.classic.Logger.log(Logger.java:824)
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.error(SLF4JLocationAwareLog.java:225)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:415)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:114)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.cache.interceptor.CacheInterceptor$1.invoke(CacheInterceptor.java:58)
at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:213)
at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622)
.......................
at java.lang.Thread.run(Thread.java:701)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:297)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:52)
... 18 more
This error happens when spring applications jar are rebuilt, removed, or updated during execution.
Ref: https://github.com/spring-projects/spring-boot/issues/4968
I have been getting this same error when breaking out (ctrl-c) from Dropwizard server, I finally learned why I get it.
My Dropwizard is build into one fat jar, that I build with Gradle, and when running server on my local computer I run it directly from build/libs/...fat.jar
So this exception occurs when I have changed source code, built app-server again, and Gradle has overwritten the same jar I am currently running with "java -jar ...", so it's not that weird that classes that haven't been used before that session will not load ok :)
This type of exception occurs when your classpath does not contain this class. If the jar's class is in your classpath, you pay attention to what classpath application you using at runtime. Indeed, often, classpath can be overwritten during runtime, or simply you can use a different one (for example, in a startup script).
For us, appears this meant "you are running out of file handles, increase your open file handle limit." (too many sockets were being created, using them all up). Credit to the original answer here.
Other things I've seen: make sure your spring boot is at least 1.3.8
Also make sure the jars underneath aren't being overwritten/changed/unstable file system. FWIW.
I got this runtime error in my spring boot app using Spring Boot version 2.3.5.RELEASE. Resolved by adding following dependencies in my build.gradle file.
compile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
compile group: 'ch.qos.logback', name: 'logback-core', version: '1.2.3'
Two options I see(not enough information yet):
1. It happens right upon loading, I bet for classpath, see answers above.
2. It happens after some time, when app is runnig(my case), read next paragraphs.
When I got class not found errors and also have the same error like you right now, quite offten is issued with no space left on device aka full disk, full memory.
My environment, is spring boot, logback is included automagicaly, in maven have repackage, so wverithing I need is included.
This error occures after my app is runnig for 20 minutes or so, is has thousands of threads. If you do not limit memory for your virtual maschine, it can get very high even if it is not necessary.
Once(2 days ago) I spend 3 hours looking around claspath stuf, ... issue was full disk
If you exactly ensure that logback-class and logback-core already are in your classpath. See below.
In your Logback.xml, you need add debug="true"
<configuration debug="true">
I encountered the problem 'java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy' in my tomcat.
However, after adding debug = 'true', anything is ok.
The class that is missing definitely exists in the JAR you have, I checked logback-classic-1.0.1.jar:
2012-03-07 07:34:18 ..... 4729 2018 ch\qos\logback\classic\spi\ThrowableProxy.class
Make sure your classpath is set up correctly. By the way: if possible update logback because this version is 3 years old.
I solved this problem by doing "mvn install" instead of "mvn clean install".
Related
I am attempting to run an Eclipse 3.x application using Equinox in Neon as initiated in this question.
It appears that my remaining issue is that the LogReaderService appears to not be available, as the second line below in org.eclipse.core.internal.runtime.InternalPlatform.getLog() appears to throw a NullPointerException:
ExtendedLogReaderService logReader = logReaderTracker.getService();
logReader.addLogListener(result, result);
An implementation of this class can be found in org.eclipse.osgi, which I am launching the application with. For whatever reason, though, the service is null, which causes a number of plug-ins to throw exceptions when logging since many of the plug-ins rely on getting the Logging service from the Activator.
Since org.eclipse.osgi contains the implementation in its internals, I assumed that it would also register the service. That does not appear to be the case. I have also tried including log4j and org.apache.felix.log and neither appear to resolve this problem.
There must be something simple that is missing here to get the LogService to start? Here's the stack trace:
Caused by: java.lang.ClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.core.resources (44).
at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:116)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:529)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 20 more
Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.core.resources.ResourcesPlugin.start() of bundle org.eclipse.core.resources.
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:795)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:470)
at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
... 29 more
Caused by: java.lang.NullPointerException
at org.eclipse.core.internal.runtime.InternalPlatform.getLog(InternalPlatform.java:353)
at org.eclipse.core.runtime.Platform.getLog(Platform.java:976)
at org.eclipse.core.internal.utils.Policy.log(Policy.java:159)
at org.eclipse.core.internal.resources.Workspace.setCrashed(Workspace.java:2302)
at org.eclipse.core.internal.resources.SaveManager.restoreSnapshots(SaveManager.java:963)
at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:720)
at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1587)
at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2399)
at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2156)
at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:464)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:774)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:767)
... 36 more
I also added
Require-Capability: osgi.service;filter:="(objectClass=org.osgi.service.log.LogService)";effective:=active
To one of the dependent bnd files. This did not appear to solve the problem.
Edit: Because the OSGI Framework is set to org.eclipse.osgi in the bndrun file, is that preventing the logging from getting initialized? I have also tried adding org.apache.commons.logging as well as osgi.enroute.equinox.log.adapter and I am still getting NPEs when anything attempts to log. The org.eclipse.osgi bundle is already considered running by the time the RCP plugins get activated... yet there is no ExtendedLogReaderService. Do I need to find a way to install Felix as the Core Runtime in order to make org.eclipse.osgi able to get started by the framework in order for the ExtendedLogReaderServiceImpl to get registered?
I have found numerous examples of how to listen for the LogService... I'm not seeing how to start the ExtendedLogService.
Edit 2: I am able to suppress the LogService nulls issue by registering dummy ExtendedLogService implementations.
The problem has been resolved (finally), revisiting this now that our build system is in place the solution was likely that osgi.enterprise was not a Required-Bundle which also caused caused our OSGI-JDBC services to not work properly when testing the deployed target platforms.
Additionally, our primary RCP plug-in (containing the Application class, etc.) did not have a Bundle-ActivationPolicy: lazy clause in the *.bnd files used to generate the MANIFEST.MF file which lead to some other problems.
Just in case anyone else runs into such problems.
I created the war file and deployed into tomcat server but while submitting the registration page(having recaptcha) this error is happening, but not in the local machine and app running in the local machine using the GGTS IDE.
Following is the error happening in the production server
errors.GrailsExceptionResolver - ClassNotFoundException occurred when processing request: [POST] /IFP/signup/completeSignUp
grails.plugins.rest.client.RestBuilder. Stacktrace follows:
java.lang.ClassNotFoundException: grails.plugins.rest.client.RestBuilder
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethods(Class.java:1975)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at com.megatome.grails.recaptcha.ReCaptcha.checkAnswer(ReCaptcha.groovy:171)
at com.megatome.grails.RecaptchaService.verifyAnswer(RecaptchaService.groovy:147)
at com.controllers.portal.SignupController.completeSignUp(SignupController.groovy:42)
at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:198)
at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
at grails.plugin.springsecurity.web.filter.GrailsAnonymousAuthenticationFilter.doFilter(GrailsAnonymousAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.RequestHolderAuthenticationFilter.doFilter(RequestHolderAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter.doFilter(MutableLogoutFilter.java:62)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
From my view this exception is happening after the implementation of recaptcha.
Please help me for resolving this issue.
java.lang.ClassNotFoundException: grails.plugins.rest.client.RestBuilder
states clearly that this class is missing in your production war or Tomcat.
Make sure you are setting proper dependencies in your gradle config as per plugin ref-doc:
compile "org.grails.plugins:rest-client-builder:2.1.1"
Check that those jars are also present in your war or Tomcat's classpath
Copying the file grails-datastore-rest-client-3.1.4.RELEASE.jar into the tomcat lib folder resolved the problem.
You can download the jar file from here.
If someone is still looking for the answer: Please add the line below to build.gradle and it should work (pulls in a necessary dependency):
implementation 'org.grails:grails-datastore-rest-client:6.1.9.RELEASE'
I'm rewriting a client/server application using Akka 2.2.0, Java 1.7.0_25 and Eclipse Juno.
I had a sample client and server working with Akka 2.0.2.
I updated to the old stable release 2.1.4 and got everything working once again.
I've just moved to the latest stable release 2.2.0.
I created a new package to add some new functionality, leaving the existing code untouched.
Something changed and now I can't launch my test cases.
Here is the stacktrace I see when I try to create an ActorSystem:
Exception in thread "main" java.lang.ClassNotFoundException: [B
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at akka.actor.ReflectiveDynamicAccess.getClassFor(DynamicAccess.scala:94)
at akka.serialization.Serialization$$anonfun$4.apply(Serialization.scala:154)
at akka.serialization.Serialization$$anonfun$4.apply(Serialization.scala:153)
at scala.collection.TraversableLike$WithFilter$$anonfun$map$2.apply(TraversableLike.scala:697)
at scala.collection.immutable.HashMap$HashMap1.foreach(HashMap.scala:178)
at scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:347)
at scala.collection.TraversableLike$WithFilter.map(TraversableLike.scala:696)
at akka.serialization.Serialization.<init>(Serialization.scala:153)
at akka.serialization.SerializationExtension$.createExtension(SerializationExtension.scala:15)
at akka.serialization.SerializationExtension$.createExtension(SerializationExtension.scala:12)
at akka.actor.ActorSystemImpl.registerExtension(ActorSystem.scala:644)
at akka.actor.ExtensionId$class.apply(Extension.scala:34)
at akka.serialization.SerializationExtension$.apply(SerializationExtension.scala:12)
at akka.remote.RemoteActorRefProvider.init(RemoteActorRefProvider.scala:77)
at akka.actor.ActorSystemImpl._start(ActorSystem.scala:568)
at akka.actor.ActorSystemImpl.start(ActorSystem.scala:575)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:103)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:98)
at akka.actor.ActorSystem$.create(ActorSystem.scala:64)
at akka.actor.ActorSystem.create(ActorSystem.scala)
Its complaining that it can't class load a byte array via the method descriptor style string "[B".
#som-snytt pointed out two bug reports that exactly describe the error I'm seeing.
#paul-vargas called out -Dsun.lang.ClassLoader.allowArraySyntax=true which re-enables the old loadClass behavior.
The allowArraySyntax flag does make the ClassNotFoundException go away but other errors popped up. The errors lead me to believe that something has gone wrong with my Eclipse/m2e/Scala-ide/Akka setup.
I imported the project into Netbeans 7.3 and did a clean and build and it worked on the first try. I didn't even need to set allowArraySyntax.
May you need add the argument to VM:
-Dsun.lang.ClassLoader.allowArraySyntax=true
This won't be news to everyone:
http://bugs.sun.com/view_bug.do?bug_id=6500212
http://bugs.sun.com/view_bug.do?bug_id=6434149
I only looked that up due to #paul-vargas.
I observe that in trunk, ReflectiveDynamicAccess uses Class.forName as the bug report says is recommended. See the code on master.
Possibly, you'll want to upgrade your Akka together with your Java version.
Or, perhaps your production runtime is stuck on 1.5 but you develop on 1.7.
Old akka and scala jars were on the classpath along with the updated versions. Not sure why it caused the above exception but the problem became obvious once Paul pointed out the allowArraySyntax flag.
I'm getting following exception when open my GWT app in development mode. the exact same code can compile successfully using mvn gwt:compile
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3667 at
com.google.gwt.dev.asm.ClassReader.readClass(ClassReader.java:1976)
at com.google.gwt.dev.asm.ClassReader.accept(ClassReader.java:464)
at com.google.gwt.dev.asm.ClassReader.accept(ClassReader.java:420)
at
com.google.gwt.dev.shell.rewrite.HasAnnotation.hasAnnotation(HasAnnotation.java:45)
at
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1100)
at
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1203)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:247) at
com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:665)
at
com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:468)
at
com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:49)
at com.google.gwt.core.shared.GWT.create(GWT.java:57) at
com.google.gwt.core.client.GWT.create(GWT.java:85) at ...
I overdid ModuleSpace.java and printed out the class name at line 665 before Class.forName() which points out it is trying to load the generated GinjectorImpl.java
I found out my generated GinjectorImpl.java is about 9MB and with 100K+ lines of code.
When I randomly remove some modules from my GWT app it works again, so I'm guessing it is too large for ASM to compile.
Any suggestions? Thanks
Environment:
GWT 2.5.0, GIN 1.5.0, gwt-maven-plugin 2.5.0, Java 6 SE
Try deleting the gwt-unitCache folder and run a gwt-compile again. This fixed it for me.
Upgrade GIN to 2.0.0 fixed my problem
size of the generated Ginjector.java shrink from 110K+ lines to 23 lines :)
I've got a Java web application (using Spring), deployed with Jetty. If I try to run it on a Windows machine everything works as expected, but if I try to run the same code on my Linux machine, it fails like this:
[normal startup output]
11:16:39.657 INFO [main] org.mortbay.jetty.servlet.ServletHandler$Context.log>(ServletHandler.java:1145) >16> Set web app root system property: 'webapp.root' = [/path/to/working/dir]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:151)
at org.mortbay.start.Main.start(Main.java:476)
at org.mortbay.start.Main.main(Main.java:94)
Caused by: java.lang.ExceptionInInitializerError
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:129)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:51)
at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.http.HttpServer.doStart(HttpServer.java:708)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.jetty.Server.main(Server.java:460)
... 7 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.springframework.util.SystemPropertyUtils.(SystemPropertyUtils.java:42)
... 14 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 18 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 24 more
[shutdown output]
I've run the app with java -verbose:class, and according to that output, org.apache.log4j.Category is loaded from the log4j JAR in my /WEB-INF/lib, just before the first exception is thrown.
Now, the Java versions on the two machines are slightly different. Both the machines have Sun's java, the Linux machine has 1.6.0_10, while the Windows machine has 1.6.0_08, or maybe 07 or 06, I can't remember the exact number right now, and don't have the machine at hand. But even though the minor versions of the Javas are slightly different, the code shouldn't break like this. Does anyone understand what's wrong here?
You must understand that a classloader can't see everything; they can only see what a parent classloader has loaded or what they have loaded themselves. So if you have two classloaders, say one for Jetty and another for your webapp, your webapp can see log4j (since the JAR is the WEB-INF/lib) but Jetty's classloader can't.
If you manage to make a class available to Jetty (for example something in the DB layer) which uses log4j but which ends up running in the context (and classloader) of Jetty, you will get an error.
To debug this, set a breakpoint in org.springframework.web.util.Log4jWebConfigurer.initLogging(). If you can, copy the source of this class into your project (don't forget to delete it afterwards) and add this line:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Have a look at the cl object in your debugger. That should give you some information who created it. My guess is that this is the classloader from Jetty.
[EDIT] Note that you get in a different mess if you have log4j in both classloaders: In this case, you will have two classes with the same name which create objects which are not assignment compatible! So make sure there is only a single instance of this jar or that instances of log4j will never be passed between the two contexts (which is usually not possible).
This seems like a classic classloader problem. It could be due to another web app being loaded first which also uses log4j but a version that is different to the one used by the app you are testing. The classloader uses the first version of the class it finds. The server class loading policy can usually be changed in the config files. Sorry I am a bit rusty on this but maybe it can point you in the correct direction.
Make sure there are no other installed apps on the web server,
Make sure the log4j being loaded is the correct version,
Make sure you don't have a log4j lurking somewhere in the classpath of the server.
HTH
You're using the same WAR on both machines? Have you checked if the WAR files are identical (no transfer errors occured)?
Some random things to consider:
(1) Check if there are any other versions of log4j floating around on the linux instance, outside of the web-app directories?
(2) Is apache commons logging being used at all? You might want to consider SLF4J instead?
(3) Did the JAR/WAR become corrupt in some way - was it FTP'ed in ASCII or Binary?
(4) Print out the classloader hierarchy in each case, just to see if there are any discrepancies?
Even though the original problem was solved for the asker, I'll point out that a common source of problems when running the same code on Windows vs Linux (or Unix) is case-sensitivity issues. Windows ignores case while Linux or Unix is case-sensitive. This has bitten me more than once.
So if you specify a jar or directory on the classpath, but it isn't the right case then it will fail on Linux but succeed on Windows. This can also be the source of FileNotFoundExceptions.
Had the same problem and found an easy solution/workaround:
In Eclipse in Preferences > Java > Installed JREs, select the JRE > Edit and Add External JARs... and browse to your log4j.jar.
The other workaround is to add log4j.jar to every launch definition in Classpath tab.