We Keep Coding

Grails: Exception with RestBuilder only while running in production tomcat server

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'

java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy?

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".

ClassLoader classcastexception with activemq client

I have been struggling with this problem for a while now, decided to ask the community, hoping to get some hints/answers.
I am using tomcat 7.0.54 as my J2EE container which has a WAR deployed with dependency on activemq-all.
Along with the above, I'm also placing a jar in the classpath to register a listener programmatically, by implementing the ServletContainerInitializer interface. This initializes a simple implementation of an active mq client, JvmMessageProducerImpl (I have activemq-client as a dependency in the pom).
With the above setup, when i try to start tomcat, i get the below exception. It seems that instead of loading the classes independently, the listener which is called when the web application starts, is finding an existing instance of TcpTransportFactory and throwing the ClassCastException. I have read the classloader manual for tomcat multiple times, and my understanding is that each of the war files should have independent Class loaders - but dont completely understand why the exception is being thrown?
javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [tcp]
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:317)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:330)
at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:251)
at com.monitoreverywhere.jvmmon.mq.JvmMessageProducerImpl.setup(JvmMessageProducerImpl.java:66)
at com.monitoreverywhere.jvmmon.mq.JvmMessageProducerImpl$Runner.run(JvmMessageProducerImpl.java:163)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.IOException: Transport scheme NOT recognized: [tcp]
at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:181)
at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:63)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:315)
... 5 more
Caused by: java.lang.ClassCastException: org.apache.activemq.transport.tcp.TcpTransportFactory cannot be cast to org.apache.activemq.transport.TransportFactory
at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:178)
... 7 more

ClassNotFoundException after instrumenting with cobertura

Using JBoss AS 7.1.1 I want to get code coverage after testing of my project, deployed as an .war.
It seemingly works as expected until the point where I am starting the server. Here is the error message:
13:20:49,571 SEVERE [net.sourceforge.cobertura.coveragedata.TouchCollector] (MSC service thread 1-8) Exception when registering class: com/project/Creator: java.lang.ClassNotFoundException: com.project.Creator from [Module "org.jboss.as.server:main" from local module loader #30c01f1c (roots: C:\Jboss\jboss-as-7.1.1.Final\modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.1.GA]
at
An important part may be that without using --auxClasspath argument, I did get errors instrumenting this class because of dependencies. This should be fixed by the mentioned argument though.
Edit:
There are in two situations where I get problems.
During instrumentation, using the following command for instrumentation
C:\cobertura\cobertura-2.0.3\cobertura-instrument.bat" --basedir C:\Jboss\jboss-as-7.1.1.Final\standalone\deployments project.war --datafile C:\Jboss\jboss-as-7.1.1.Final\bin\cobertura.ser --auxClasspath ""C:\workspace\jboss-build\src\com\arbitrage\j2ee\common\dto\TypeData.java
which gives me the error
java.lang.RuntimeException: java.lang.ClassNotFoundException: com.arbitrage.j2ee.common.dto.TypeData
at net.sourceforge.cobertura.instrument.CoberturaClassWriter.getCommonSuperClass(CoberturaClassWriter.java:35)
But, when I start up JBoss, it does so without giving any errors.
However, when I stop JBoss I get this error:
ERROR [stderr] Exception in thread "Thread-45" java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/TouchCollector$ApplyToClassDataLightClassmapListener
In the second case instrumentation goes well with the following command
C:\cobertura\cobertura-2.0.3\cobertura-instrument.bat" addInstrumentationToArchive C:\Jboss\jboss-as-7.1.1.Final\standalone\deployments\screator.war --includeClasses "com.project.*" --datafile C:\Jboss\jboss-as-7.1.1.Final\bin\cobertura.ser --auxClasspath "C:.m2\repository\com\project\1\project-1.jar
Which gives me an OK
INFO: Cobertura: Saved information on 41 classes.
Now the problem occurs when starting up JBoss
SEVERE net.sourceforge.cobertura.coveragedata.TouchCollector Exception when registering class: com/project/Creator: java.lang.ClassNotFoundException: com.project.Creator from [Module "org.jboss.as.server:main" from local module loader #30c01f1 (roots: C:\Jboss\jboss-as-7.1.1.Final\modules)].
etc etc.
I have added -Djboss.shutdown.forceHalt=false to the VM arguments.
Help is much appreciated,
Thanks!

Why would Java classloading fail on Linux, but succeed on Windows?

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.