NoSuchMethodError exception from Java MapReduce pipeline POST /mapreduce/workerCallback? - java

Do you know of a workaround for this uncaught exception from the Java mapreduce pipeline on Google App Engine?
Is it simply a failure in GcsServiceFactory that created GCS_SERVICE in this line?
https://code.google.com/p/appengine-mapreduce/source/browse/trunk/java/src/com/google/appengine/tools/mapreduce/inputs/GoogleCloudStorageLineInputReader.java?r=462#80
Any ideas on how to fix?
We are seeing this frequently:
2013-09-24 18:18:17.819 Uncaught exception from servlet
java.lang.NoSuchMethodError:
com.google.appengine.tools.cloudstorage.GcsService.openPrefetchingReadChannel(Lcom/google/appengine/tools/cloudstorage/GcsFilename;JI)Ljava/nio/channels/ReadableByteChannel;
at com.google.appengine.tools.mapreduce.inputs.GoogleCloudStorageLineInputReader.beginSlice(GoogleCloudStorageLineInputReader.java:79)
at com.google.appengine.tools.mapreduce.impl.WorkerShardTask.run(WorkerShardTask.java:84)
at com.google.appengine.tools.mapreduce.impl.shardedjob.ShardedJobRunner.runTask(ShardedJobRunner.java:265)
at com.google.appengine.tools.mapreduce.impl.shardedjob.ShardedJobServiceImpl.handleWorkerRequest(ShardedJobServiceImpl.java:49)
at com.google.appengine.tools.mapreduce.impl.handlers.MapReduceServletImpl.doPost(MapReduceServletImpl.java:76)
at com.google.appengine.tools.mapreduce.MapReduceServlet.doPost(MapReduceServlet.java:57)

I see any of the below possible reasons :
You did not include all the jars in classpath, they might have
interdependent classes.
You jar is an old version which is not
having that method.
Some dependent jar is missing which not allowing the class constructor to initialize the class object.

Related

AWS Beanstalk + Kotlin + Spring boot: NoSuchMethodException main()

I've a Spring Boot app written in Kotlin that I have deployed to AWS Beanstalk that is throwing the following exception:
Exception in thread "main" java.lang.NoSuchMethodException: com.prototype.demo.DemoApplication.main([Ljava.lang.String;)
at java.base/java.lang.Class.getDeclaredMethod(Class.java:2675)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:47)
Locally, when I run the app from IntelliJ I've no issues.
I have the spring-boot-maven-plugin and the kotlin-maven-plugin in my project.
Any ideas about what could be causing the issue? I previously built a similar app in Java but didn't run into this issue.
Thank you for your expertise and time.
Update: something interesting to notice is that I had to set in the properties of my POM the following line in order to make the project executable by IntelliJ during development (i had forgotten about it): <start-class>com.prototype.demo.DemoApplication</start-class>
Now I've removed it and I get a different error when running the jar file. I will spend some time on it and see if that's related or not and update the question accordingly.
Thank you!
The issue was raised by the following property declared in my POM file: <start-class>com.prototype.demo.DemoApplication</start-class>.
Once I removed it and added the open keyword to the Configuration annotated classes and to the DemoApplication(the class containing the main) it finally worked.
Solution for build.gradle.kts
I had the same problem when deploying my application to ECS.
First things first:
When you see such an error in AWS logs -> do as the author of the question has done and test the issue locally. Most probably if the application is failing on AWS, it will also fail on you local machine. To do so, you build a jar locally, the jar file is usually saved in build/libs/application-x.x.x-SNAPSHOT.jar and run java -jar application-x.x.x-SNAPSHOT.jar
Now you can fix your build task and test it locally before deploying it again.
Fix Gradle:
My main method was defined in MyApplication.kt file, but in the definition of the main class in gradle I had to set the following:
tasks.getByName<org.springframework.boot.gradle.tasks.bundling.BootJar>("bootJar") {
mainClass.set("com.company.app.MyApplicationKt")
}
Notice: MyApplicationKt
That is the only thing I had to change for me to fix this issue.

Google Protobuf VerifyError

I am using Google Protobuf version 2.6.1 and wanted to use the option
option optimize_for = LITE_RUNTIME;
I am getting the following exception as soon as I do so.
Exception in thread "main" java.lang.VerifyError: class com.pbo.common.network.message.NetworkProtocol$NetworkMessage$HpSyncMessage overrides final method com.google.protobuf.GeneratedMessageLite.isInitialized()Z
As soon as I remove the lite runtime option, the error goes away. Not sure what's causing this. I tried cleaning gradle caches etc to see if that helps but to no avail.

How can I fix the NoClassDefFoundError error that occurs when using evosuite to generate test cases?

I got this error when I used evosuite to generate test cases with my android project.
In the beginning, there was such an error:“can not find this class:android.support.v7.widget.Toolbar” I solved this problem by adding Android's jar package:collections-28.0.0.jar into CP path, and then the following error occurred in the process of automatically generating use cases for multiple files:
[MASTER] 21:22:39.979 [logback-2] ERROR TestClusterGenerator - Problem for com.rapidapp.base.account.AppBaseService. Failed to add dependencies for class android.support.v7.widget.Toolbar: java.lang.NoClassDefFoundError: android/support/v7/widget/Toolbar$SavedState
[java.lang.Class.getDeclaringClass0(Native Method), java.lang.Class.getDeclaringClass(Class.java:1235), java.lang.Class.getEnclosingClass(Class.java:1277), java.lang.Class.getSimpleBinaryName(Class.java:1443), java.lang.Class.getSimpleName(Class.java:1309), java.lang.Class.isAnonymousClass(Class.java:1411), org.evosuite.setup.TestUsageChecker.canUse(TestUsageChecker.java:155), org.evosuite.setup.TestUsageChecker.canUse(TestUsageChecker.java:338), org.evosuite.setup.TestClusterGenerator.addDependencyClass(TestClusterGenerator.java:975), org.evosuite.setup.TestClusterGenerator.resolveDependencies(TestClusterGenerator.java:358), org.evosuite.setup.TestClusterGenerator.generateCluster(TestClusterGenerator.java:137), org.evosuite.setup.DependencyAnalysis.analyze(DependencyAnalysis.java:118), org.evosuite.setup.DependencyAnalysis.analyzeClass(DependencyAnalysis.java:132), org.evosuite.TestSuiteGenerator.initializeTargetClass(TestSuiteGenerator.java:110), org.evosuite.TestSuiteGenerator.generateTestSuite(TestSuiteGenerator.java:130), org.evosuite.rmi.service.ClientNodeImpl$1.run(ClientNodeImpl.java:145), java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511), java.util.concurrent.FutureTask.run(FutureTask.java:266), java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142), java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617), java.lang.Thread.run(Thread.java:745)]
Finally, a use case is not generated.
I have experienced This exception before, when (trying) to run code which had been compiled on one operating system on another. Also, when updates have occurred to the OS.
Though you might have thought that backwards compatibility should remove this later, it is not always the case!

Exception in thread "main" org.apache.velocity.exception.VelocityException

Does anyone know how can I solve this problem?
I am trying to make a connection with amazonMechanicalTurk using Java API.
Exception in thread "main"
org.apache.velocity.exception.VelocityException: Error initializing
log: org.apache.log4j.Logger object set as runtime.log.logsystem is
not a valid log implementation.
Caused by: org.apache.velocity.exception.VelocityException:
org.apache.log4j.Logger object set as runtime.log.logsystem is not a
valid log implementation.
Do yourself a favor, working with Velocity I've learned that is better to shut down his damn log:
//disabling Velocity log
Velocity.setProperty("runtime.log.logsystem.class", "org.apache.velocity.runtime.log.NullLogSystem");
I just decided to add some other Velocity libraries to my project.
My project only had the Apache Velocity jar file, then from here, I also added Velocity-Dep to my Maven project and Yesssssssssss! VICTORY!
Still asking why?!! because my project was working well until I decided to update java-aws-mturk library to version 1.7.0; then after I got that error!

OpenSAML Issue - NoClassDefFoundError for TrustMaterial (Java7, Maven)

We are seeing the following error when trying to complete a single-sign-on using OpenSAML. This was working, then seemed to stop when we upgraded to Java 7 (though that could very well be a red herring). We did install the JCE, so don't think it's related to that. Has anyone encountered this before?
java.lang.NoClassDefFoundError: Could not initialize class org.apache.commons.ssl.TrustMaterial
org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:319)
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:194)
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:169)
org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider.extractCertificates(InlineX509DataProvider.java:191)
org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider.process(InlineX509DataProvider.java:125)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfoChild(BasicProviderKeyInfoCredentialResolver.java:299)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfoChildren(BasicProviderKeyInfoCredentialResolver.java:255)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfo(BasicProviderKeyInfoCredentialResolver.java:189)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.resolveFromSource(BasicProviderKeyInfoCredentialResolver.java:148)
org.opensaml.xml.security.credential.AbstractCriteriaFilteringCredentialResolver.resolve(AbstractCriteriaFilteringCredentialResolver.java:57)
org.opensaml.xml.security.credential.AbstractCriteriaFilteringCredentialResolver.resolve(AbstractCriteriaFilteringCredentialResolver.java:37)
org.opensaml.security.MetadataCredentialResolver.retrieveFromMetadata(MetadataCredentialResolver.java:266)
Ensure not-yet-commons-ssl-0.3.9.jar is on the classpath of the JVM. That is the jar that contains the TrustMaterial class.

Categories

Resources